On 8/6/07, Guillermo Espertino wrote:

A couple of weeks ago somebody commented about the quality of the downscaling in Gimp.
iirc there was a patch that improved the quality (that was bumped for future releases) and there was a discussion about the pertinence of the different names of the algorithms in the interface. Well, I know that this kind of requests are not welcome when a new release is so near, but I've been using Gimp a little more this days for small images (my previous works were for print or signs, so I didn't find this issue to be critic), but now I do and I'd like to share my experiences and my concerns.
I'm working in a website right now, and one of the most frequent operations is to reduce images. I coudn't get a decent reduction using the different algorithms.
If you have to reduce a very large image to, say 800 px, you can use oversampling and you get a decent result, but when you're working on images for the web, which are frequently smaller than 100px, the results are very bad.
If you use oversampling, the result is a blurred image. If you don't you get jagged edges.This is particularly visible when you work with type, logotipes or high contrast images.

You don't appear to be using oversampling, as you say:

If you perform the transformation just once, the imperfections are visible. But the big problem comes when you have to perform transformations a couple of times.

Oversampling cancels that out, because the increased resolution minimizes loss of meaningful data. (oversampling == editing at a increased resolution relative to intended final size.) Perhaps you mean supersampling?

And this operations are not rare. It's very common to scale down an image, rotate it and then tweak the size again.

For now, you should rotate before scaling down if possible.

The last time I mentioned this, Sven replied:

I might be wrong but I think the current algorithms are basically the same as the ones used in GIMP 2.2. So there's really no point in addressing this long-standing but minor issue before 2.4.

I thought then that it was ok, but I've changed my mind. It's not minor at all. Since Gimp doesn't support CMYK, it is not a viable tool for image processing for print, so we have a tool mostly for screen works. One of the main professional applications for that is preparing images for the web, and this issue is critic for that kind of work.
As a little example, I had to create a button for changing a website's language. I had a high resolution flag of the UK and wanted to reduce it. I coudn't get the image right, by any means. I had to re-draw it using single pixels (I know that diagonal lines are difficult to represent in small sizes, so don't start to call me stupid. I made the same work before with other software and got better results).

This is an artefact of the way downscaling currently works: it examines 2x2 pixels for each output pixel. This means if you're downscaling to less than 50%, some source pixels are ignored. If Cubic was properly implemented for downscaling, it would examine 4x4 pixels for each output pixel, and some pixels would be ignored when scale < 25%.

Presently, the solution to this is to scale down incrementally (reduce scale by 50% until you approach the desired scale, and then scale down to that exact size.)

Maybe GIMP could implement the above workaround before 2.4. It would be inefficient (scaling down the image N times instead of once) but it would mean that the result was correctly dependant on ALL the source pixels.

Non-destructive transformation is something that would be more sensible to implement after 2.4.

The release of the 2.4 will be a huge event. The program went through very important changes, and it's becoming a truly professional application. If you compare 2.3.x with 2.2.x the difference is impressive. Now Gimp looks and feel professional. It would be a shame to inherit that limitation from 2.2 series and have to wait until the next version (which, considering the whole GEGL thing. won't be ready soon).
Please don't take this comments as another stupid user request. This is very important and for me is the major issue that obstaculizes my migation to Gimp.
I'd like to have CMYK, of course, but color management is enough for now, since CMYK is not a small change. I'm not telling that's a small change either, but I think it's critic enough to take a look before 2.4 I've discussed this with several users and they share my point of view. I'd like to know what you guys think about it, and if it's possible, revise the situation before 2.4

Thanks in advance, Gez.

Guillermo Espertino (gespertino@gmail.com) wrote:

David Gowers wrote:

Perhaps you mean supersampling?

Yes, it must be. I'm using a spanish localization of Gimp and try to guess the correct translation.
Is there a command line option to launch gimp in english (just once, not permanent) so I can use the correct words when I'm reporting a bug or discussing something like this?

Try
LANG=C gimp

AFAIK this works in most unix shells, most notably in bash.

Bye, Simon

Hi,

On Sun, 2007-08-05 at 21:20 -0300, Guillermo Espertino wrote:

Presently, the solution to this is to scale down incrementally (reduce scale by 50% until you approach the desired scale, and then scale down to that exact size.)

Nice tip. I'll try it.
It's not that comfortable but at least is a workaround.

There are scripts available for scaling down in several steps. Just use them.

Anyway, there is no point at all in pointing out how important such a change would be. Several people have tried to improve the downscaling quality over the last two years. Do you seriously suggest that we wait another two years with GIMP 2.4? So unless you have a patch that we can apply immidiately, this discussion is pointless.

Sven

Guillermo Espertino wrote:
> [...reasons..]
> I'm out of here.

Sad to hear, input from users are important, even if not all developers agree on all suggestions made by all users. You are welcome to return any day.

- Martin Nordholts

Hi,

On Mon, 2007-08-06 at 13:27 -0300, Guillermo Espertino wrote:

I'm trying to say that if this version took 2.4 years of development, it would be a pitty if all the new stuff come together with this long time issue.

Yes. It's a pity. But without a working patch we don't have much of a choice.

Sven

Hi,

On Mon, 2007-08-06 at 13:27 -0300, Guillermo Espertino wrote:

You're absolutely right. This discussion is pointless. If you suggest that a script for scaling down in several steps is a valid solution you know as much about image manipulation as I do about coding. So don't waste each other's time.
I'd be happy if you choose to listen to the users, even if they can't make a patch. But since the first time I was here, I see the same: every suggestion a user makes, you almost call him stupid.

First of all, I didn't call you or anyone else stupid. Second, this is a developer list. If you want to make a user suggestion without going into implementation details, then please use the gimp-user mailing-list for that.

The point you raised is handled in our bug-tracker and it was high on the priority list for 2.4. Unfortunately it has not been resolved yet. As a member of the gimp-developer list, I expect you to know that. There is not much point in bringing it up again since that is not likely going to help. That's why I call this a pointless discussion for the developer list.

Sven

Sven Neumann wrote:

Second, this is a
developer list. If you want to make a user suggestion without going into implementation details, then please use the gimp-user mailing-list for that.

Id like to see this followed more strictly. people who post feature requests, to be pointed in the right direction. - it dosnt have to be rude.

These seems to be tension between developers and users who want to influence the development direction of the gimp.

This adds a fair bit of noise to the list and means the quality of discussion is lower with interjections by people who are not developers and dont appreciate the purpose of the list.

Im not a gimp developer so I cant speak for you guys, but from my involvement in other open source projects and reading development mailing lists, this problem is especially bad here.

for Blender3d we have a "Blender functionality" list, since discussing improvements to software isnt exactly a user issue either.

http://lists.blender.org/mailman/listinfo/bf-funboard http://lists.blender.org/pipermail/bf-funboard/2007-March/thread.html

features can be kicked out on this list and suggestions made be non-developers without friction.

Sven Neumann wrote:

Hi,

On Mon, 2007-08-06 at 13:27 -0300, Guillermo Espertino wrote:

You're absolutely right. This discussion is pointless. If you suggest that a script for scaling down in several steps is a valid solution you know as much about image manipulation as I do about coding. So don't waste each other's time.
I'd be happy if you choose to listen to the users, even if they can't make a patch. But since the first time I was here, I see the same: every suggestion a user makes, you almost call him stupid.

First of all, I didn't call you or anyone else stupid. Second, this is a developer list. If you want to make a user suggestion without going into implementation details, then please use the gimp-user mailing-list for that.

The point you raised is handled in our bug-tracker and it was high on the priority list for 2.4. Unfortunately it has not been resolved yet. As a member of the gimp-developer list, I expect you to know that. There is not much point in bringing it up again since that is not likely going to help. That's why I call this a pointless discussion for the developer list.

Sven

On 8/7/07, Geert Jordaens wrote:

I can't seem to find the associated bug. Does anybody know which is the bug report?
I've got a test version (for scale-funcs.c) that scales down in reducing the image 1/4 each step.
Between each step a the image is blurred before starting the next reduce cycle.
The final step performs a bilinear interpolation.

1000 x 1000 => blur (3x3 gauss) => 500 x 500 => blur (3x3 gauss) => 250x250 => bilinear interpolation => 200x200

I don't understand why you gauss-blur 3x3. won't this percolate roughly .3 of each pixel into it's neighbours (in terms of the scaled down result), and thus, isn't this an aesthetic choice rather than a technical one?
Trying it out myself it makes things look too blurry. It's great for simple antialiasing enhancement, but it tends to damage detail. Doing it without the blur IMO looks better, proportionate to the amount of detail in the original.

BTW: the current algorithym you implemented has the following problems: * Layers with alpha are treated improperly -- the resultant alpha channel tends to be completely wrong. * Layers where width is not even, become skewed to 45 degrees after scaling.

If you would replace the gauss+downscale with just downscaling, that would be good. Why do you use the gaussian blur?

David Gowers wrote:

On 8/7/07, Geert Jordaens wrote:

I can't seem to find the associated bug. Does anybody know which is the bug report?
I've got a test version (for scale-funcs.c) that scales down in reducing the image 1/4 each step.
Between each step a the image is blurred before starting the next reduce cycle.
The final step performs a bilinear interpolation.

1000 x 1000 => blur (3x3 gauss) => 500 x 500 => blur (3x3 gauss) => 250x250 => bilinear interpolation => 200x200

I don't understand why you gauss-blur 3x3. won't this percolate roughly .3 of each pixel into it's neighbours (in terms of the scaled down result), and thus, isn't this an aesthetic choice rather than a technical one?
Trying it out myself it makes things look too blurry. It's great for simple antialiasing enhancement, but it tends to damage detail. Doing it without the blur IMO looks better, proportionate to the amount of detail in the original.

BTW: the current algorithym you implemented has the following problems: * Layers with alpha are treated improperly -- the resultant alpha channel tends to be completely wrong. * Layers where width is not even, become skewed to 45 degrees after scaling.

If you would replace the gauss+downscale with just downscaling, that would be good. Why do you use the gaussian blur?

I did some reading on image pyramid's (googling) and there the blur action is described as a low pass filter. Factoring the blur out is not a problem. I also have to look to the non-uniform scaling as mentioned by Sven and odd size. If those things get fixed would this be a viable solution?

Geert

g4@catking.net wrote:

On Wed, 08 Aug 2007 11:57:00 +0200, Geert Jordaens wrote:

I did some reading on image pyramid's (googling) and there the blur action is described as a low pass filter. Factoring the blur out is not a problem. I also have to look to the non-uniform scaling as mentioned by Sven and odd size. If those things get fixed would this be a viable solution? Geert

Well blurring is technically a low-pass filter but such a crude one you would not want to look at it's frequency profile.

It's a rather crude way of masking imperfections rather than applying a correctly designed filter appropriate to the scaling being done.

/gg

What would be a correctly designed filter for scaling down by factor 2?

Geert

Hi,

On Wed, 2007-08-08 at 13:58 +0200, Geert Jordaens wrote:

What would be a correctly designed filter for scaling down by factor 2?

I'd say the code in app/base/tile-pyramid.c, in particular tile_pyramid_write_quarter() counts as a well-done and efficient filter for this purpose.

Sven

PS: I am sure though that this code could be written more efficiently using SIMD instructions. But I will leave that to be done for someone else...

On 8/8/07, Sven Neumann wrote:

On Wed, 2007-08-08 at 13:58 +0200, Geert Jordaens wrote:

What would be a correctly designed filter for scaling down by factor 2?

I'd say the code in app/base/tile-pyramid.c, in particular tile_pyramid_write_quarter() counts as a well-done and efficient filter for this purpose.

This code implements a perfect box filter for this case, what needs to be added on top
of this to be able to do good estimate (maybe even exact) box filter resamplings is trilinear interpolation by doing bilinear interpolation on the two closest 50% 25% 12.5% .. levels of the scaled pyramid. The current GIMP view implements nearest neighbour interpolation on the nearest larger level, and the GEGL code (which the GIMP code is based on) uses bilinear interpolation on the closest larger level. If someone wants to work on creating the coded needed to implement trilinear (linear interpolation between bilinear on the larger and smaller versions than the exact scale, it is work that is needed for both GIMP itself internally on the short term and externally when all this code becomes deprecated by the migration to GEGL.

If adding such functionality to the GIMP itself it would perhaps be best to do it by directly reusing the code paths used by the display code.

/Øyvind K.

Øyvind Kolås wrote:

This code implements a perfect box filter for this case, what needs to be added on top
of this to be able to do good estimate (maybe even exact) box filter resamplings is trilinear interpolation by doing bilinear interpolation on the two closest 50% 25% 12.5% .. levels of the scaled pyramid.

I'd suggest having a read of Graphics Gems I, page 147, "Filters For Common Resampling Tasks" by Ken Turkowski. Box and tent filters are easy to implement, but not necessarily the best choices...

Graeme Gill.

On 8/9/07, Graeme Gill wrote:

Øyvind Kolås wrote:

This code implements a perfect box filter for this case, what needs to be added on top
of this to be able to do good estimate (maybe even exact) box filter resamplings is trilinear interpolation by doing bilinear interpolation on the two closest 50% 25% 12.5% .. levels of the scaled pyramid.

I'd suggest having a read of Graphics Gems I, page 147, "Filters For Common Resampling Tasks" by Ken Turkowski. Box and tent filters are easy to implement, but not necessarily the best choices...

For downscaling (decimating) box filtering is orders of magnitude better than the buggy erronious use of interpolation that currently is used in GIMP. More theoretically correct resampling methods like a Sinc filter with an infinite neighbourhood definitly is not something one would want in the view code. I also doubt you will see much of a difference when doing things like generating thumbnails etc. My gut feeling is that high quality resampling matters
a lot more for other transformations than downscaling.

/Øyvind K.

On Thu, 2007-08-09 at 19:35 +0200, Øyvind Kolås wrote:

For downscaling (decimating) box filtering is orders of magnitude better than the buggy erronious use of interpolation that currently is used in GIMP.

For what it's worth, for www.fromoldbooks.org, I routinely scale images down to 20% or smaller of original width; I find that the GIMP "Lancsoz" and "Cubic" modes produce very different results. Sometimes one is better and sometimes the other.

It's a difficult test because the engravings often have patterns of almost-horizontal slightly-wavy lines that are, say, between 6 and 9 pixels apart... so you get strange artifacts appearing.

Sometimes I try a gaussian blur before downsizing, too, e.g. with a radius of 3 or 5 or so; sometimes I use "value propagate" first.

Liam

Øyvind Kolås wrote:

More theoretically correct
resampling methods like a Sinc filter with an infinite neighbourhood definitly is not something one would want in the view code.

I suggest reading the article, rather than jumping to the conclusion that a Sinc filter is a recommended option.

Of course if near enough is good enough, then a box filter will work acceptably.

Graeme Gill.

Hi,

just sending this link again since I dont think my last post got to the m.l.

It's the article Graeme refers to which covers all this rather well.

http://www.worldserver.com/turk/computergraphics/ResamplingFilters.pdf

/gg

On Fri, 10 Aug 2007 04:34:03 +0200, Graeme Gill wrote:

Øyvind Kolås wrote:

More theoretically correct
resampling methods like a Sinc filter with an infinite neighbourhood definitly is not something one would want in the view code.

I'm not sure what you mean by view code here. Preview?

Sinc filter with infinite window is clearly a theoretical abstraction that can never be implemented. That's why Lanczos derived his finite windows function (in around 1930 IIRC!).

I suggest reading the article, rather than jumping to the conclusion that a Sinc filter is a recommended option. Of course if near enough is good enough, then a box filter will work acceptably.
Graeme Gill.

http://www.worldserver.com/turk/computergraphics/ResamplingFilters.pdf

Reading the article you refer to clearly shows the frequency response of all these options. The crudity of box and tent is an incentive to find a better option. Lanczos would seem to be one better option if it can be correctly implemented on reduction.

Why do you say anyone is jumping to conclusions? Lanczos (L3 would be likely to be used) gives best suppression of side lobes and more passband than gaussian the only other option without huge side lobes that give heavy artifacts.

As Øyvind Kolås pointed out this may be much more relevant for other operations such as rotation and scew.

/gg

Øyvind Kolås wrote:

On 8/9/07, Graeme Gill wrote:

Øyvind Kolås wrote:

This code implements a perfect box filter for this case, what needs to be added on top
of this to be able to do good estimate (maybe even exact) box filter resamplings is trilinear interpolation by doing bilinear interpolation on the two closest 50% 25% 12.5% .. levels of the scaled pyramid.

I'd suggest having a read of Graphics Gems I, page 147, "Filters For Common Resampling Tasks" by Ken Turkowski. Box and tent filters are easy to implement, but not necessarily the best choices...

For downscaling (decimating) box filtering is orders of magnitude better than the buggy erronious use of interpolation that currently is used in GIMP. More theoretically correct resampling methods like a Sinc filter with an infinite neighbourhood definitly is not something one would want in the view code. I also doubt you will see much of a difference when doing things like generating thumbnails etc. My gut feeling is that high quality resampling matters
a lot more for other transformations than downscaling.

/Øyvind K.

I get the feeling that we are mixing 2 things here.

1. scaling for display purposes (uniform X and Y scaling) 2. scaling as a effective drawing transformation. (X and Y scale can be different)

The tile-pyramid as it is now seems to me only usefull for the 1ste case.

If the downscaling is rewritten (completed) then it should be for display.

1. Calculate the image pyramid.
[filter] -> [:2] -> [filter] -> [:2] -> [filter] -> [:2]
2. Linear interpolate between level and level-1
I leave in the middle if the [filter] is a box, gauss or sinc filter.

For the downscaling as a effective drawing transformation, the pyramid can only be used
for reducing to the maximum X and Y scale in 2D. What afterwarts only, in 1D for the smaler scale?

scale X = 0.15 scale X = 0.30

[filter] -> [:2] (2D X and Y)
[filter] -> [:2] (1D X)

Geert

Hi,

On Fri, 2007-08-10 at 10:54 +0200, Geert Jordaens wrote:

I get the feeling that we are mixing 2 things here.

1. scaling for display purposes (uniform X and Y scaling) 2. scaling as a effective drawing transformation. (X and Y scale can be different)

For the second case, it only needs a small modification to the pyramid solution. Instead of always scaling down both directions, one could optionally scale by 50% in vertical or horizontal direction only. This would allow you to reduce the image to a size that is close enough to the destination size. From there on, you can do linear interpolation.

Sven