On Wed, Oct 29, 2008 at 10:37 PM, Claus Berghammer (Bugzilla)
> 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
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)
Gimp-developer mailing list

Reply via email to