Re: [Gimp-developer] Scaling in Gimp 2.6 is much slower than in Gimp 2.4
Hi Liam, On Fri, Oct 31, 2008 at 11:55 AM, Liam R E Quin [EMAIL PROTECTED] wrote: On Fri, 2008-10-31 at 01:44 +0100, Joern P. Meier wrote: [...] By the way, what kind of downscaling is used for the view zooming? GEGL is doing that. GEGL is not doing that. GEGL certainly has display-pyramid code, but GIMP does not currently use GEGL's implementation, it has it's own (app/base/tile-pyramid.c) As far as I understand it, each step of the image-pyramid is produced by averaging every 2x2 pixel square from the step above it. If the zoom matches exactly one of the stored pyramid levels, it is used directly in the display.. Otherwise, it interpolates between the next smaller step and the next bigger step to produce the display. HTH, David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Scaling in Gimp 2.6 is much slower than in Gimp 2.4
Hi, On Fri, 2008-10-31 at 17:46 +1030, David Gowers wrote: As far as I understand it, each step of the image-pyramid is produced by averaging every 2x2 pixel square from the step above it. If the zoom matches exactly one of the stored pyramid levels, it is used directly in the display.. Otherwise, it interpolates between the next smaller step and the next bigger step to produce the display. Right. And that is pretty close to what the scaling code does. It also averages 2x2 pixel squares until it gets close enough to the final size. The last step differs though. But we have discussed the downscaling code before. Let's not start this again. Instead of going through this discussion again, please read the thread in the archive. Then please sit down and write a patch that implements proper decimation. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Scaling in Gimp 2.6 is much slower than in Gimp 2.4
On Fri, 2008-10-31 at 17:46 +1030, David Gowers wrote: GEGL is doing that. GEGL is not doing that. GEGL certainly has display-pyramid code, but GIMP does not currently use GEGL's implementation, it has it's own (app/base/tile-pyramid.c) Oops, sorry, I must have misunderstood soemthing pippin said (Øy vey!). Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Scaling in Gimp 2.6 is much slower than in Gimp 2.4
Hi, Sven Neumann wrote: On Wed, 2008-10-29 at 23:52 +0100, Joern P. Meier wrote: The new Gimp 2.6 Cubic option usually yields too bad quality to be considered (I won't even begin with Linear). I guess you are running into bug #556248 here (which will be 'fixed' in 2.6.2). That may well be the case. I also noticed huge differences in quality depending on the target image size (tough I almost never scale to exactly 50%). By the way, what kind of downscaling is used for the view zooming? It is usually quite good (even with odd scaling factors). I wouldn't mind having a comparable quality in the final result. Cheers, Joern ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Scaling in Gimp 2.6 is much slower than in Gimp 2.4
On Fri, 2008-10-31 at 01:44 +0100, Joern P. Meier wrote: [...] By the way, what kind of downscaling is used for the view zooming? GEGL is doing that. I have found that for scanned engravings, where I often scale down to 11% or smaller, that GIMP 2.6 is not only much faster, but usually has much better results. Sometimes I scale down part-way with Lancsoz and then the rest of the way with cubic, though, to minimise artefacts. Applying a convolution filter (a blur, in this case) before scaling down, or using Value Propagate with more black (for an engraving or woodcut) can also make a really huge improvement sometimes. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Scaling in Gimp 2.6 is much slower than in Gimp 2.4
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: (Time for operation WITHOUT image window redraw) Gimp 2.6: Interpolation: None: 1,54 Interpolation: Linear: 2,46 Interpolation: Cubic:5,80 Interpolation: Lanzcos: 15,12 Gimp 2.4: Interpolation: None: 0,0 (no progressbar noticeable) Interpolation: Linear: 3,51 Interpolation: Cubic:3,35 Interpolation: Lanzcos: 22,15 Visual Comparison Gimp Scaledown: Interpolation None: Both do show distorted faces. Overall quality is the same. Prefer 2.4 because its faster with same quality. Interpolation Linear: Alignment of pixels varies (images jumps from one 2.4 layer to 2.6 layer, borders are aligned). The distorted faces problem from above ist still present, but masked by blur. So the eyes of person 1 has more blur in the gimp 2.4 layer, and vice versa. Like above: No version offers overal better result, so I prefer the old (faster) version. Interpolation Cubic: Alignment of pixels like above. BUT, 2.6 does indeed deliver noticeable better results than 2.4 here. Means that BOTH faces are sharper, than in the 2.4 layer. Interpolation Lanzcos: Alignment of pixels like above. Visual Quality of 2.4 and 2.6 is the same. Prefer 2.4 code, since it is MUCH faster. Benchmarking GIMP Upscale Performance: Scale layer from 768x576px - 1500x1500px: (Time for operation WITHOUT image window redraw) Gimp 2.6: Interpolation: None: 0,50 Interpolation: Linear: 1,21 Interpolation: Cubic:2,27 Interpolation: Lanzcos: 5,51 Gimp 2.4: Interpolation: None: 0,0 (no progressbar noticeable) Interpolation: Linear: 0,60 Interpolation: Cubic:0,91 Interpolation: Lanzcos: 8,18 Visual Comparison Gimp Upscale: Interpolation None: 2.4 and 2.6 absolute identical in result (tested with difference blendmode) Interpolation Linear, Cubic and Lanzcos: Alignment is different*, beside that, the image is 100% identical (* the layer has to be moved 1 pixel up and left in 2.4, or down and right in 2.6 to have the same alignment [200% Scale]) I also have tested with scale factor not being 200%. In that case I cannot use the blendmode, since I cannot align the layers right. But visually there was also no difference between 2.4 and 2.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? 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... Sincerely, Claus Berghammer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Scaling in Gimp 2.6 is much slower than in Gimp 2.4
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 Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Scaling in Gimp 2.6 is much slower than in Gimp 2.4
David Gowers writes: ... 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) In my opinion, here is the best way to handle this: The driver (GUI) could catch that there is a enlarge in one direction, shrink in the other, first do the enlargement with the user's selected method (keeping the other dimension fixed), then do the reduction with box filtering (keeping the other dimension fixed. It is important to perform the upsampling before the downsampling. - Alternative: The GUI could have TWO sets of choices: Upscaling method: None, linear, cubic, lanczos Downsampling method: None, linear, box (say) with only one toggle being taken into account when the same type of operation is applied in both directions (of course). Nicolas Robidoux Universite Laurentienne/Laurentian University ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Scaling in Gimp 2.6 is much slower than in Gimp 2.4
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@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Scaling in Gimp 2.6 is much slower than in Gimp 2.4
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) [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 Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Scaling in Gimp 2.6 is much slower than in Gimp 2.4
Hi, On Wed, 2008-10-29 at 22:06 +0100, Claus Berghammer (Bugzilla) wrote: 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. Please read my other reply. Your interpretation of the numbers is just plain wrong. With the patch from the bug report, GIMP 2.6 is faster and provides better quality. Please get your facts straight first. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Scaling in Gimp 2.6 is much slower than in Gimp 2.4
Hi, I don't think the performance is the biggest issue. However, the results of current (i.e. Gimp 2.6.x) downscaling are. In Gimp 2.4 I could use the Cubic Option which resulted in a little blurring, but that could be fixed with a judicious use of the Sharpen filter. So in the end, it yielded a lot of control about the final result. The new Gimp 2.6 Cubic option usually yields too bad quality to be considered (I won't even begin with Linear). This also applies to Lanczos in some cases, but at least that option is somewhat useful. In any case, the results look like Gimp 2.4 with an overdone Sharpen filter applied (20 or more) or so which results in ultra-sharp downscaled images. Though it is acceptable for several typical cases and may be what people expect of a default downscaling behavior, that is not always what is required by the artist. So, yes, different scaling options are a good idea. And they also should yield usable results (do not sharpen automatically, and if that is done, it should be an option as well). Cheers, Joern ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Scaling in Gimp 2.6 is much slower than in Gimp 2.4
Claus: You wrote: 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? ;-) For the record: I was being totally serious. The users who happen to know that there is no simple method which does really well for both (drastic) upsampling and (drastic) downsampling may be happy to see that different methods are used for the two different cases. To reiterate: Once methods good for downsampling (like box) and upsampling (like bicubic and lanczos) are implemented, either: We make the choice for the users of which method is used (ideally using two different methods something different is done in different directions, for example, bicubic in the enlargement direction(s) and box in the shrinking direction(s) if the user chose bicubic), which more or less is what David suggested; or We choose defaults for them but make it visible that we use different methods in different directions, allowing them to modify the default choices, which is my suggestion. Implementation note: If two different methods are used, do the upsampling with the better for enlargements method first (unless you can do them both at once, but this is quite challenging programming wise). This approach is slower, but will give better results. nicolas ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Scaling in Gimp 2.6 is much slower than in Gimp 2.4
Hi, On Wed, 2008-10-29 at 23:52 +0100, Joern P. Meier wrote: I don't think the performance is the biggest issue. However, the results of current (i.e. Gimp 2.6.x) downscaling are. In Gimp 2.4 I could use the Cubic Option which resulted in a little blurring, but that could be fixed with a judicious use of the Sharpen filter. So in the end, it yielded a lot of control about the final result. GIMP 2.4 did not implement a Cubic option for downscaling. You effectively used Linear. The new Gimp 2.6 Cubic option usually yields too bad quality to be considered (I won't even begin with Linear). I guess you are running into bug #556248 here (which will be 'fixed' in 2.6.2). The result of that bug is that scaling down by a factor of 0.5 results in no interpolation at all. Even with that fixed, I would still like to see an improvement for the downscaling algorithm in 2.6. If we could have a proper decimation algorithm to replace the current code, I would even consider applying that for a 2.6 release. Hopefully we can switch to GEGL at some point for scaling. As far as I can see there is now a promising upscaling implementation available there. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
