No, my benchmark was NOT intended to come close to yours ;-) My main interest 
was the time it takes for processing. I only tested ONE image, not several in 
several resolutions...

Its clear to me, that different scale factors can/will result in different 
quality of images.

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.


David Gowers schrieb:
> Hi,
> On Wed, Oct 29, 2008 at 10:37 PM, Claus Berghammer (Bugzilla)
> <[EMAIL PROTECTED]> 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)
Gimp-developer mailing list

Reply via email to