Hi,

On Wed, Oct 29, 2008 at 10:37 PM, Claus Berghammer (Bugzilla) wrote:

Hello Gimp Developers,

Sven Neumann asked me to move this thread from the Users mailinglist, to developers. The original discussion can be found here: http://www.nabble.com/Scaling-in-Gimp-2.6-is-much-slower-than-in-Gimp-2.4-to20185528.html

There is also a Bug in Bugzilla: http://bugzilla.gnome.org/show_bug.cgi?id=557950

I extended my benchmarks and visual comparisons I've made so far, to give an more detailed view on whats the problem.

Short said, it is all about: "Why is 2.6 so slow on scaling, compared to 2.4." ;-) See yourself:

Benchmarking GIMP Scaledown Performance:

Scale layer from 5000x5000px -> 2500x2500px:

Is this a representative usage? I did a comprehensive benchmark (http://svenfoo.org/scaletest/)
which showed the new code produced markedly better defined results, on pictures ranging from 277x185 to 1600x1200. That comprehensive benchmark was one of the main reasons this patch ended up in 2.6. In particular, you can see that the new algorithym preserves detail more accurately (see the Circular Zone plate, test image #6)

Conclusion:
Since the difference in processing time shows up even with interpolation "None", I think that the origin is not within the interpolation algorithms (or at least not only). Instead it seems to me (of course I'm just a user, not a developer), that there are some changes in the resize algorithm itself. If I understood the stuff in bug #464466 right, the scale routine is used several times in the interpolation routine. So, if the resize routine is slow, it accumulates in the interpolation routine.

The speed penalty in 2.6 is more than just noticeable, and keeps some users away from 2.6.

Also interesting is, the different alignment in 2.4 and 2.6. Why are layers that are processed with 2.4 always a bit "left and above" its 2.6 counterpart?

2.4 had some problematic behaviour on borders leading to the entire result often being wrongly offset.

It isn't really a problem, but if this isn't technical necessary, the behavior should be identical, to maintain "project compatibility" between different users/gimp versions.

As Sven Neumann already mentioned (see http://bugzilla.gnome.org/show_bug.cgi?id=557950), the upscaling could be made faster easily.

But I think, that there is room for performance improvements in downscaling too...

It is certainly possible. As Sven pointed out, we should probably first address the craziness of using interpolation routines (linear, cubic, lanczos) for downscaling. Do we even need to offer a choice of algorithym for downscaling (Box filter of appropriate size should be ok, except for None, which should be obvious.)? This is tricky because the user can downscale and upscale in one pass (eg. 150% scale on x axis, 80% on the y axis)

David Gowers writes:
> ...
> It is certainly possible. As Sven pointed out, we should probably > first address the craziness of using interpolation routines (linear, > cubic, lanczos) for downscaling. Do we even need to offer a choice of > algorithym for downscaling (Box filter of appropriate size should be > ok, except for None, which should be obvious.)? This is tricky because > the user can downscale and upscale in one pass (eg. 150% scale on x > axis, 80% on the y axis)

In my opinion, here is the best way to handle this:

The driver ("GUI") could catch that there is a "enlarge in one direction, shrink in the other," first do the enlargement with the user's selected method (keeping the other dimension fixed), then do the reduction with box filtering (keeping the other dimension fixed.

It is important to perform the upsampling before the downsampling.

-----

Alternative:

The GUI could have TWO sets of choices:

Upscaling method: None, linear, cubic, lanczos

Downsampling method: None, linear, box (say)

with only one toggle being taken into account when the same type of operation is applied in both directions (of course).

Nicolas Robidoux Universite Laurentienne/Laurentian University

Hi,

On Wed, 2008-10-29 at 13:07 +0100, Claus Berghammer (Bugzilla) wrote:

Benchmarking GIMP Scaledown Performance:

Scale layer from 5000x5000px -> 2500x2500px:

This particular case (downscaling by 50%) is broken in GIMP 2.6.0 and 2.6.1. A workaround is in SVN and will be in the 2.6.2 release. You can't compare the quality without this fix.

As Sven Neumann already mentioned (see http://bugzilla.gnome.org/show_bug.cgi?id=557950), the upscaling could be made faster easily.

Not the upscaling that you benchmarked here. What can be made faster easily is the case that you presented in the bug report (upscaling by a factor of 10). This is done in multiple passes right now. And I can't think of a good reason why this is not done in a single step. So we could apply the patch attached to that bug report.

For GIMP 2.8 we should at least review the downscaling code. We need proper decimation code. The current approach that uses interpolation is inherently broken.

But I think, that there is room for performance improvements in downscaling too...

I've spent quite a few time optimizing this code before the 2.6 release. The original patch was up to eight times slower than what we have now. I doubt that you can further speed it up much without changing the underlying algorithm.

Sven

Hi,

On Wed, 2008-10-29 at 21:03 +0100, Claus Berghammer (Bugzilla) wrote:

But this benchmark represents, what an "average" user notice at first: Gimp 2.6 needs much more time, and doesn't deliver that much more quality.

Sorry, but your benchmark doesn't show a dramatic slowdown. The impact is very noticeable when scaling up by a large factor, but that is already taken care by the proposed patch (that is now in trunk for testing).

Your interpretation of the numbers is somewhat questionable also. Scaling without interpolation simply had no progress indicator in GIMP 2.4. So that's why you don't notice any progress. The operation still takes time though. Also GIMP 2.4 did not implement downscaling using Cubic interpolation, it always used Linear. Now that you know that, let's look at your numbers again. You will notice that downscaling in GIMP 2.6 is actually faster than in GIMP 2.4:

Scale layer from 5000x5000px -> 2500x2500px:

GIMP 2.4 GIMP 2.6 Interpolation: None: ???? 1.54 Interpolation: Linear: 3.51 2.46 Interpolation: Cubic: ---- 5.80 Interpolation: Lanzcos: 22.15 15.12

Let's look at the upscaling operation. The scale factor you tried is implemented in a two-step scaling in GIMP 2.6. This is addressed by the patch that I proposed. If you would redo your benchmark with that patch applied, you would get about the same speed for upscaling in 2.6 than what you measured for 2.4. Actually I would not be surprised if 2.6 would also perform slightly better here.

Sven

Hi,

On Wed, 2008-10-29 at 22:06 +0100, Claus Berghammer (Bugzilla) wrote:

I just can repeat myself, the old routines were "good enough" for most cases/people, so I would like to see the option, to use it alongside the new code. This could be easily (from a user's perspective ;-) done, by a "HQ" checkmark in the scale window. If it is unchecked, gimp uses the old and fast code. If checked, the new "better but slower" code is used.

Please read my other reply. Your interpretation of the numbers is just plain wrong. With the patch from the bug report, GIMP 2.6 is faster and provides better quality. Please get your facts straight first.

Sven

Hi,

I don't think the performance is the biggest issue. However, the results of current (i.e. Gimp 2.6.x) downscaling are.

In Gimp 2.4 I could use the "Cubic" Option which resulted in a little blurring, but that could be fixed with a judicious use of the "Sharpen" filter. So in the end, it yielded a lot of control about the final result.

The new Gimp 2.6 "Cubic" option usually yields too bad quality to be considered (I won't even begin with "Linear"). This also applies to "Lanczos" in some cases, but at least that option is somewhat useful. In any case, the results look like Gimp 2.4 with an overdone Sharpen filter applied (20 or more) or so which results in ultra-sharp downscaled images. Though it is acceptable for several typical cases and may be what people expect of a default downscaling behavior, that is not always what is required by the artist.

So, yes, different scaling options are a good idea. And they also should yield usable results (do not sharpen automatically, and if that is done, it should be an option as well).

Cheers,

Joern

Claus:

You wrote:

I don't want to say much about what type of interpolation is good for what and when, since I don't have the knowledge that for. But 2 things I'd like to comment:

1.) No more interpolation Options?

David Gowers mentioned: "Do we even need to offer a choice of algorithym for downscaling (Box filter of appropriate size should be ok, except for None, which should be obvious.)?"

I can hardly imagine not to have the choice of interpolation for downscaling. Different interpolations give different results, and sometimes you want it a bit crisper, sometimes a bit softer...

2.) Interpolation options separately for Up- and Down-Scaling?

Nicolas Robidoux said, that as an alternative [to a smarter algorithm], he could imagine separate GUI Options for Up- and Down-Scaling.

I think, most user will think upon that: "It's a joke, isn't it?" ;-)

For the record:

I was being totally serious.

The users who happen to know that there is no simple method which does really well for both (drastic) upsampling and (drastic) downsampling may be happy to see that different methods are used for the two different cases.

To reiterate:

Once methods good for downsampling (like box) and upsampling (like bicubic and lanczos) are implemented, either:

We make the choice for the users of which method is used (ideally using two different methods something different is done in different directions, for example, bicubic in the enlargement direction(s) and box in the shrinking direction(s) if the user chose bicubic), which more or less is what David suggested;

or

We choose defaults for them but make it visible that we use different methods in different directions, allowing them to modify the default choices, which is my suggestion.

Implementation note:

If two different methods are used, do the upsampling with the "better for enlargements" method first (unless you can do them both at once, but this is quite challenging programming wise). This approach is slower, but will give better results.

nicolas

Hi,

On Wed, 2008-10-29 at 23:52 +0100, Joern P. Meier wrote:

I don't think the performance is the biggest issue. However, the results of current (i.e. Gimp 2.6.x) downscaling are.

In Gimp 2.4 I could use the "Cubic" Option which resulted in a little blurring, but that could be fixed with a judicious use of the "Sharpen" filter. So in the end, it yielded a lot of control about the final result.

GIMP 2.4 did not implement a "Cubic" option for downscaling. You effectively used "Linear".

The new Gimp 2.6 "Cubic" option usually yields too bad quality to be considered (I won't even begin with "Linear").

I guess you are running into bug #556248 here (which will be 'fixed' in 2.6.2). The result of that bug is that scaling down by a factor of 0.5 results in no interpolation at all. Even with that fixed, I would still like to see an improvement for the downscaling algorithm in 2.6. If we could have a proper decimation algorithm to replace the current code, I would even consider applying that for a 2.6 release.

Hopefully we can switch to GEGL at some point for scaling. As far as I can see there is now a promising upscaling implementation available there.

Sven

On Wednesday 29 October 2008, Nicolas Robidoux wrote:

Implementation note:

If two different methods are used, do the upsampling with the "better for enlargements" method first (unless you can do them both at once, but this is quite challenging programming wise). This approach is slower, but will give better results.

Whatever your final thoughts might be, please keep in mind that there are cases where there's both enlargement and shrinking in the same layer, and where you can't simply decompose them into vertical and horizontal parts (think perspective transform) or where horizontal or vertical distances and areas are conserved (rotating, shearing). Interpolation is necessary in these cases as well.

Daniel

Hi,

Sven Neumann wrote:

On Wed, 2008-10-29 at 23:52 +0100, Joern P. Meier wrote:

The new Gimp 2.6 "Cubic" option usually yields too bad quality to be considered (I won't even begin with "Linear").

I guess you are running into bug #556248 here (which will be 'fixed' in 2.6.2).

That may well be the case. I also noticed huge differences in quality depending on the target image size (tough I almost never scale to exactly 50%).

By the way, what kind of downscaling is used for the view zooming? It is usually quite good (even with odd scaling factors). I wouldn't mind having a comparable quality in the final result.

Cheers,

Joern

On Fri, 2008-10-31 at 01:44 +0100, Joern P. Meier wrote: [...]

By the way, what kind of downscaling is used for the view zooming?

GEGL is doing that.

I have found that for scanned engravings, where I often scale down to 11% or smaller, that GIMP 2.6 is not only much faster, but usually has much better results. Sometimes I scale down part-way with Lancsoz and then the rest of the way with cubic, though, to minimise artefacts. Applying a convolution filter (a blur, in this case) before scaling down, or using Value Propagate with "more black" (for an engraving or woodcut) can also make a really huge improvement sometimes.

Liam

Hi Liam,

On Fri, Oct 31, 2008 at 11:55 AM, Liam R E Quin wrote:

On Fri, 2008-10-31 at 01:44 +0100, Joern P. Meier wrote: [...]

By the way, what kind of downscaling is used for the view zooming?

GEGL is doing that.

GEGL is not doing that. GEGL certainly has display-pyramid code, but GIMP does not currently use GEGL's implementation, it has it's own (app/base/tile-pyramid.c)

As far as I understand it, each step of the image-pyramid is produced by averaging every 2x2 pixel square from the step above it. If the zoom matches exactly one of the stored pyramid levels, it is used directly in the display.. Otherwise, it interpolates between the next smaller step and the next bigger step to produce the display.

HTH, David

Hi,

On Fri, 2008-10-31 at 17:46 +1030, David Gowers wrote:

As far as I understand it, each step of the image-pyramid is produced by averaging every 2x2 pixel square from the step above it. If the zoom matches exactly one of the stored pyramid levels, it is used directly in the display.. Otherwise, it interpolates between the next smaller step and the next bigger step to produce the display.

Right. And that is pretty close to what the scaling code does. It also averages 2x2 pixel squares until it gets close enough to the final size. The last step differs though.

But we have discussed the downscaling code before. Let's not start this again. Instead of going through this discussion again, please read the thread in the archive. Then please sit down and write a patch that implements proper decimation.

Sven

On Fri, 2008-10-31 at 17:46 +1030, David Gowers wrote:

GEGL is doing that.

GEGL is not doing that. GEGL certainly has display-pyramid code, but GIMP does not currently use GEGL's implementation, it has it's own (app/base/tile-pyramid.c)

Oops, sorry, I must have misunderstood soemthing pippin said (Øy vey!).

Liam