GNOME Bugzilla – Bug 317853
Repeated 'Image Scale' causes heavy image defects
Last modified: 2008-01-15 14:04:38 UTC
Take a color image do an image / image scale to about 110% with interpolation 'none' repeat this operation 5 times Using interpolation type 'lanczos' gives less visible defects, 'linear' shows more, 'none' much more. Using a script doing: (gimp-drawable-transform-scale TheLayer 0.0 0.0 NewWidth NewHeight TRANSFORM-FORWARD INTERPOLATION-LANCZOS TRUE 3 FALSE) gives the same results. Sample image on: http://img67.imageshack.us/my.php?image=mg12664gu.jpg
I have a fantasy that at some point GIMP will be able to recognize when the user performs a sequence of linear transformations (move, scale, rotate, shear, perspective), and use the Undo mechanism to compress them all into a single transformation performed on the starting image. But until that happens, the sort of thing described here is inevitable.
I was implementing a 'stair interpolation' method in script-fu, so compressing several scale transforms into one single operation is exactly what I don't want to do.
Regarding comment #1: Compressing transformations is the job of GEGL. It is not related to Undo. What probably could be done with the current architecture is to enable such compression in the transform tools.
Back to the original bug report... Any transformation introduces artefacts. And repeating the transformation will increase the artefacts. That isn't surprising. If you think there's a problem, please make a simple test case (for example a test image and a test script) that demonstrates the problem.
Created attachment 53067 [details] Test script to demonstrate transform artefacts
Created attachment 53068 [details] Original test image
Created attachment 53069 [details] Artefacts at 200% with linear interpolation
Created attachment 53070 [details] Artefacts at 200% with none interpolation
What I am worried about are not any 'normal' transformation artefacts but the 32*32 pixel grid that is introduced when repeating the interpolation. I think this must be related to the methods used for transforming. Cubic an Lanczos interpolation create the same artefacts, but they are a bit harder to see. BTW - I am using Gimp 2.3.4 on Windows, but 2.2.8 on Linux gives the same results.
Ok, it's apparently accumulating the error, that needs to be fixed.
I agree with the comments on "normal" artifacts from scaling or other transforms. The example given seems to be something else. I expect the artifacts from interpolation="none" should look like the distortion that you used to see on Macintoshes when you tried using a font set to a size without a bitmap defined for that size, i.e. a one pixel line would become a two pixel line in some locations, but remain a one pixel line in others. Repeated integer factor scalings with interpolation="none" should not accumulate artifacts if the fixed point of the scaling is always the same. If I scale up a pixel by a linear factor of 5 it should become a 5x5 block of pixels. If I then scale that down by a factor of 5 I should get the original image (if since the fixed point is invariant, the 5x5 grid of 'big pixels' does not change). If the fixed point varies from transform to transform, I can see how additional artifacts might arise (I presume that the color of the scaled down pixel is an average of the 5x5 block that corresponds to it. If my understanding of interpolation="none" is faulty, please explain.
bumping to Future because this will not be solved for 2.4, although it remains quite an important goal.
This seems still to be a problem in current SVN. The test script as attached unfortunately uses INTERPOLATION_NONE and it isn't very surprising that there are artefacts with interpolation turned off. But the artefacts are also clearly visible with interpolation.
It's perhaps worth noting that NONE is not none, it's nearest neighbour, which although crude should be statistically symetrical if implemented correctly. I dont see why it should create any more drift than other methods if use to apply a rotation about the centre of an image. In the case of such a rotation the artifacts should be symetrical. In the code that I have worked on NONE seems to get special treatment early on and so the code path is typically rather different from the other methods that tend to remain common longer.
Is there any chance to get this one fixed before 2.4? OK, I know, it's not planned (comment #12), but the bug is rather annoying.
We are certainly not going to block the release for this. And since there's enough to do keep everyone busy, it would probably be best if you looked at it yourself.
In response to comment #14: Nearest-neighbor is not what I would call an interpolation method. Of course it shouldn't introduce the artifacts we are seeing here, but it is difficult to predict what artifacts might stem from doing repeated scaling operations. gg, this report is not about rotation and we aren't talking about a drift here. So your comments seems pretty much out of place. If you think that some code handles NONE incorrectly, please open a bug report and point out a particular place instead of adding such irritating comments here. Thanks.
I had a look at this again. The original image attached to this bug report already has artifacts from JPEG compression. This whole bug report is outdated and bogus. Closing as INVALID.