Hello... 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. Claus David Gowers schrieb: > Hi, > > On Wed, Oct 29, 2008 at 10:37 PM, Claus Berghammer (Bugzilla) > <bugzilla2@xxxxxxxxxxxxxxxxxxxxx> 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 Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
