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
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:
> 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:
>> There is also a Bug in Bugzilla:
>> 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)
>> 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
> 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
> 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