Hello... All the responses make clear to me, that there is quiet a lot do do about scaling in gimp ;-) 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. The users would be "happy and satisfied", and the power users with "higher approach" still has the extra quality. And Developers would have more time, to rethink the whole scaling thing ;-) 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?" ;-) Seriously, I think the "quality checkbox" would give enough time to developers, so that the "scaling stuff" can be redesigned the way whatever they want, and no more "intermediate solution" would be necessary. Claus Sven Neumann schrieb: > 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 > > > _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
