GNOME Bugzilla – Bug 630298
Unexpected alpha levels after rotation
Last modified: 2016-11-16 17:20:04 UTC
This problem appears on at least one Linux implementation and the Mac implementation running under OSX 10.6.4 but it does not occur under Windows (XP or 7). Rotate a 400 x 600 pixel image 0.7 degrees about its centre (the default rotation point offered by the tool for the image). Using the left-hand side of the top edge of the image as an example, the alpha values for pixels (0,0), (1,0), (2,0) and (3,0) are 2, 1, 0, 96 under Linux and Mac OSX. Surely the corner pixel should not be less transparent than the pixels that are closer to the centre of the edge. On Windows the alpha values for the same pixels are 0, 0, 0, 80 respectively (which is the sort of sequence I would expect). It doesn't appear to matter what the contents of the image are, the alpha values for the example given are always the same. If memory serves versions before 2.6.7 exhibited similar behaviour on Windows systems. The problem isn't confined to images of the size given - I have just used that as an example that should be exactly reproducible.
Are you working on 32bit or 64bit on Linux, OS X and Windows?
I am running the 32-bit GIMP on Windows XP 32-bit and Windows 7 64-bit. - the problem does not occur. The Mac OSX test was done using GIMP 64-bit. I'm not sure about the Linux system, I will have to ask.
Apparently the Linux version is 32-bit Debian Lenny.
I have now discovered that this problem is not related to the program code produced for the different operating systems but by the interpolation setting. The problem described above manifests itself exactly as described when the interpolation method for the rotate tool is set to Sinc (Lanczos3); the problem does not occur when the interpolation method is set to Cubic. I would take this to indicate that there is an error either in the Lanczos3 algorithm or in its use by the rotate tool. I'm sure that my Windows installation had Cubic set by default and a Mac user is sure that his interpolation method was set to Lanczos3 by default. The Linux system was also set to use Lanczos3 hence the apparently different behaviours based on operating system
Does this still happen on 2.8?
(In reply to comment #5) > Does this still happen on 2.8? Yes it still happens. GIMP 2.8.2 Windows 7 64-bit professional Just reproduced the problem as follows to make sure: "File/New" "Template" field blank Image size 400 wide, 600 high 72 ppi RGB Fill with background colour (black) Set the interpolation for the rotate tool to "Sinc (Lanczos3)" "Tools/Transform Tools/Rotate" Set angle to 0.7 Centre 200,300 Rotate Now zoom right in to the top left-hand corner and use the Color Picker tool - the alpha values are as follows: (0,0) = 2, (1,0) = 1, (2,0) = 0, (3,0) = 96, (4,0) = 255 (5,0) = 255, (6,0) = 246, (7,0) = 251, (8,0) = 251
Given the eventual replacement of the existing rotation algorithm by gegl perhaps this bug is no longer worth investigation. I realise that this is not the correct place to ask questions about gegl (and would be grateful of being pointed in the correct direction for doing so) but I tried a similar rotation using the gegl rotate operation in GIMP 2.8.4. I found that the areas of the canvas that were no longer covered by the rotated image were not transparent but black with alpha levels of 255. Similarly for the uncovered areas after the gegl shear operation. My question is can the colour setting of the exposed pixels be controlled? It is useful to have them transparent - for instance having rotated an image it could then be overlayed onto another image directly without having to crop off the black areas.
This bug is fixed in master, for all interpolations, alpha levels are only increasing when you go from left to right in your example. I don't think anyone will fix this in 2.8.
As to your last question, the gegl ops integrated into the transform tools don't have this problem in master.
Thanks for sorting this.