GNOME Bugzilla – Bug 128594
Rotating layer bigger than 33565 pixels with supersampling causes problem
Last modified: 2004-10-27 19:32:34 UTC
When rotating a very wide layer, pixels which are more to the right than cca 16384 (10*1024) gets wrong alpha values. How to repeat: Create new image 20000x10 px. Fill the image with red color. Change the canvas size to 20000x200 px with the layer in the center. Then use the tool for rotating layer and rotate it "-0.15" degrees. Look at those part, which is more to the right than pixels 16000. I wanted to use this to rotate my panorama consisting of 16 images from digital camera conected together which was cca 23000x1700 pixels. I tried it than under gimp-1.2 and there it worked without any problem.
Perhaps you could make a screenshot of the problem since when I follow the steps you described, I don't see anything unusual.
Ok, screenshots are available (until the bug will be closed) at http://artax.karlin.mff.cuni.cz/~cernm0bm/gimp-bug/bug1.html
OK, I didn't resize the canvas. Now I can reproduce the problem (on Linux x86)
Happens with Cubic interpolation as well. The errors shows up exactly 2^12 pixels from the center of the rotation to the right side.
Oops, that was wrong. It shows up at pixel 2^13 (16384), measured from the left image corner.
The problem was introduced with the fix for bug #109817. The supersampling routines use fixed point math and there's probably a coordinate overflow. Disabling the supersampling code (by changing RECURSION_LEVEL to 0 in app/core/gimpdrawable-transform.c) solves this bug but reopens #109817.
There's a workaround, and this is a pretty low priority bug. Shouldn't block 2.0. Dave.
Note that after making supersampling optional for the transform tools, now this problem only happens when supersampling is enabled (see bug #109817). Lowering severity accordingly.
Bumping to 2.0.2.
Moving all bugs remaining on the 2.0.3 milestone to 2.0.4.
(Kind of) fixed bug in stable branch. Will also check it into the HEAD. 2004-07-29 Dave Neary <bolsh@gimp.org> * app/core/gimpdrawable-transform.c: Stop signed ints overflowing while getting the mean by replacing (a + b) / 2 with a / 2 + b / 2. Fixes bug #128594 for drawables less than 32K wide.
Same fix committed to HEAD. Setting bug as FIXED.
Suggested low-impact general fix: Check if any of the relevant floating point values are over 2^16 before doing 16.16 arithmetic. If they are, do floating point. Quick way to do floating point: C&P integer functions & make appropriate changes. Better suggestions appreciated :) Patch coming soon.
Are you certain that the new formula for mean doesn't introduce problems for small values? Suggested general fix: always use doubles. Before we make the code more complex by adding integer and float versions, it should be shown (using a benchmark) that integer arithmetic is significantly faster than using floats/doubles here.
Sven: There are no small values. This code is on a 16.16 pixel, which means that small values are very close to 0. The general fix would work, but the reason pippin used integers in the first place is because FP performance sucked. Dave.
Created attachment 30036 [details] [review] Patch to do supersampling with doubles sometimes This patch basically copies some of the 16.16 routines and uses doubles instead, choosing them if the input values are bigger than 2^16. This code probably isn't very nice, but it works. Dave.
While I'm at it, changing title and target, and reopening. Dave.
Can I get some feedback on that last patch? Can it be committed? Should I do some performance testing to see what the difference between fixed point & floating point is?
I just want to say that in integer math (a+b)/2 != a/2 + b/2 For example, (15+17)/2 = 32/2 = 16, but 15/2 + 17/2 = 7 + 8 = 15 Whenever a and b are both odd, the results differ by one. I don't know if that's important in this case, though. I believe one could say "(a % 2 && b % 2) ? a/2+b/2+1 : a/2+b/2" but it's of course little slower.
Noone claimed it would be the same. We only said that it is close enough.
Created attachment 33108 [details] [review] Patch making it possible to set the amount of bits used in fixed point math Added a patch that allows arbitary setting of the precision in bits for the integer and fractional part of the fixed point coordinates used. Also contains some minor code style changes. The default used now is 10bit fractional part 21bits integer part, and 1bit sign,. I think this should be sufficient until we use more than 32bit adressing.