John Leach wrote:

Hi all,

I just downloaded the 2.3.5 snapshot and had a go with the Lanczos resizing algorithm. It seems to bring out some strange artifacts in one photo (actually, the first I randomly tried).

Looking at the original, I can see what it's accentuating but it looks bad. Other photos look great, much sharper compared with the cubic algorithm. This seems rather too sharp, in the wrong place.

Is this normal?

cubic, lanczos and original examples at: http://johnleach.co.uk/downloads/gimp/

It is odd. But it should be noted that an image like this... Brushed steel, with a very, *very* short field of depth is quite rare ;) Is it the camera's aperature/focus that happens to be just below the power button, or is it blurred the image?

But still, its clearly a faulty algorithm... Quite serious as well(?)

John.

P.S: Compiled on ubuntu breezy, on i386.

_______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Hi,

Dag Rune Sneeggen wrote:

But still, its clearly a faulty algorithm... Quite serious as well(?)

This might be a silly question, but why is GIMP using interpolation at all when reducing images?

Shouldn't it be doing weighted averaging of all the source pixels that contribute to a destination pixel?

All the best, --
Alastair M. Robinson

On 11/19/05, Dag Rune Sneeggen wrote:

John Leach wrote:

Looking at the original, I can see what it's accentuating but it looks bad. Other photos look great, much sharper compared with the cubic algorithm. This seems rather too sharp, in the wrong place.

But still, its clearly a faulty algorithm... Quite serious as well(?)

Am I the only one who sees the lanczos produced image, as a near perfect resize of the original? On the other hand, cubic interpolation has clearly lost the details that you seem to not want but clearly are on the original.

On Sat, Nov 19, 2005 at 02:18:03AM +0000, "Alastair M. Robinson" wrote:

But still, its clearly a faulty algorithm... Quite serious as well(?)

This might be a silly question, but why is GIMP using interpolation at all when reducing images?

Shouldn't it be doing weighted averaging of all the source pixels that contribute to a destination pixel?

Weighted averaging is a way of interpolation.

Regarding the original image, though: at least imagemagick produces a sharp image without any artifacts when using lanczos, so maybe there is a problem.

Steve Stavropoulos wrote:

On 11/19/05, Dag Rune Sneeggen wrote:

John Leach wrote:

Looking at the original, I can see what it's accentuating but it looks bad. Other photos look great, much sharper compared with the cubic algorithm. This seems rather too sharp, in the wrong place.

But still, its clearly a faulty algorithm... Quite serious as well(?)

Am I the only one who sees the lanczos produced image, as a near perfect resize of the original?

Yes, actually looks like a very interesting resize result to me too. Guess it's pretty subjective.

--adam

Hi,

John Leach writes:

I just downloaded the 2.3.5 snapshot and had a go with the Lanczos resizing algorithm. It seems to bring out some strange artifacts in one photo (actually, the first I randomly tried).

The Lanczos implementation in CVS is buggy and unless someone shows up who fixes it, it will most likely end up being removed before the 2.4 release.

Sven

Sven Neumann wrote:

Hi,

John Leach writes:

I just downloaded the 2.3.5 snapshot and had a go with the Lanczos resizing algorithm. It seems to bring out some strange artifacts in one photo (actually, the first I randomly tried).

The Lanczos implementation in CVS is buggy and unless someone shows up who fixes it, it will most likely end up being removed before the 2.4 release.

I might take a shot at fixing that, if I can find enough time to do it.

Is it bug 305928 you mean? On first sight that is more about the interaction between Lanczos and the perspective tool than about Lanczos itself.

On 11/19/05, Roel Schroeven wrote:

Sven Neumann wrote:

The Lanczos implementation in CVS is buggy and unless someone shows up who fixes it, it will most likely end up being removed before the 2.4 release.

I might take a shot at fixing that, if I can find enough time to do it.

Is it bug 305928 you mean? On first sight that is more about the interaction between Lanczos and the perspective tool than about Lanczos itself.

The bug in the perspective tool is that the lanczos algorithm uses a different offset from bilinear/bicubic/adaptive supersampling. The discontinuity that can be observed in e.g. http://pippin.gimp.org/tmp/buggy.png is the threshold around the 1:1 resampling. The point where the code in the transform tool chooses between interpolation(lanczos) and decimation(adaptive supersampling).

The problem with using bilinear/bicubic/lanczos for decimation is (apart from being
wrong in the first place) is that you end up throwing away pixels. For bicubic a destination pixels uses information from a 4x4 source window in the original image.
This is wrong. If you for instance scale to 10% of the original image size. You need to include data from at least a 10x10px window.

/Øyvind K. --
«The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/

Hi,

Øyvind Kolås wrote:

The problem with using bilinear/bicubic/lanczos for decimation is (apart from being
wrong in the first place) is that you end up throwing away pixels. For bicubic a destination pixels uses information from a 4x4 source window in the original image.
This is wrong. If you for instance scale to 10% of the original image size. You need to include data from at least a 10x10px window.

Thank you.

So I repeat, why is the Lanczos Sinc filter (or bilinear or cubic for that matter) being used at all when reducing images?

All the best, --
Alastair M. Robinson