GNOME Bugzilla – Bug 363775
rotating image causes an offset
Last modified: 2007-05-09 08:21:35 UTC
Please describe the problem: starting a new bug from bug #167956 which is getting too long and drifting into a separate , though related, issue. Steps to reproduce: 1. create a small image 2. rotate with either the rotation tool or off the layer menu 3. note the image drifts off with each transfrom effected. Actual results: Expected results: Does this happen every time? yes Other information: I see nothing wrong with the matrix code that would justify these fudge factors. It is not the well tested matrix transforms in gdouble accuracy that are at fault, it is the numbers being fed to them. As I pointed out several weeks back the fact that these adjustments are springing up all over the place in an attempt to control the offset bug is an indication that the problem lies at least partly in the calling code. As I said in #45 the rotation is being done about the wrong point. If you try to compensate this afterwards you will incorrectly offset everytime a user puts in his own value for the centre of rotation using an even number. This is compounded by an issue that I noticed while looking into this: that the dot shown in the rotation dlg is centred on the point coordinate (x,y) and not the pixel (x,y). This also means that the centre of rotation is offset from what the user intends if he uses the dot as a reference to align the rotation. These effects are most readily seen if testing with an image of about 21x32 px at 1000% zoom.
I see two issues to resolve here. 1/ Trivial: recode the dot that indicates the centre of rotation to be drawn about the centre of the target pixel not it's upper left-hand corner. 2/ Allow the coordinate input couplet to take fp rather than interger input. This will allow the user to correctly centre on and even pixel width (which we all do by habit when chosing an image size) and allow the rotate tool on the layer menu to correctly centre when it opens rather than inducing an offset every time. It could be restrained to .5 increments which would be sufficient to resolve the bug or entirely free like the rotation angle input. This would not impact on the interpolation code since all methods interpolate continuously between adjacent points. It would require some simple changes to the tool functions that currently take integer arguements, although this would obviously be pretty straight forward as well. All the matrix code is gdouble so should be unaffected. Comments please.
Does this fix the confusion? 2006-10-24 Michael Natterer <mitch@gimp.org> * app/tools/gimprotatetool.c (gimp_rotate_tool_dialog): show two decimal digits when editing "Pixels" in the "Center" size entry. Addresses bug #363775.
*** Bug 340486 has been marked as a duplicate of this bug. ***
Well I would say that the spot is much better. I am seeing quite a few other anomolies that I need to look into before commenting but you might want to look at repeated lanczos rotations. Do you think it would make sense for the spin control arrows to increment in 0.5 now. If the mid point comes at say 22.5 it seems a bit odd going to 23.5 24.5 without passing 23,24 ...
IMHO the spinbuttons should always bahave the same. Adding some voodoo when the values are at .5 would be more confusing than helpful. I suppose the other anomalies apply to lanczos in general, not only to rotate? Should this bug be closed or the summary changed?
>>IMHO the spinbuttons should always bahave the same. agreed >>Adding some voodoo when the values are at .5 would be more confusing than helpful. agreed , I was suggesting always 0.5 increments now the input is non-integer and will come up as xxx.5 at least half the time. >>I suppose the other anomalies apply to lanczos in general. No, there are no offsets on Lanczos resize (at least if my scale-funcs patches have been committed which they may not have. I get tired of campaigning to get commitals.) There was some really messy stuff going on with lanczos rotate last time I looked. First one seems OK , then it gets ugly. I am still of the opinion having worked quite a bit on this , that wanting to use lanczos for resize does not imply wanting lanczos for all other transform operations. I suggested a couple of months back that this linkage was inappropriate and that the two should have separate prefered interpolation options. It was met with a polite "thanks for you comments" from Bill and then dropped. Now may be a good time to look again at this idea. Not because lanczos rotate is broken but because rotate and rescale are fundementally different in nature and what is best for one may not be best for the other.
OK, I've had time to have another look at this on a clean cvs build. Looking a lot better but still some minor oddities. 1/ Doing cubic rotate I see the initial dot comes up nice and central now but when I go for a 15 deg the preview comes up with an offset similar to the original bug. Good news is the result is OK. Still it's a bit messy and confusing to the user to see the preview drift off. 2/ On bringing up the rotation dlg the stop is centred correctly but if I use the spin button I notice the image itself shifts 1px to the right AND the spot can no longer be centred . Each scroll increment takes it too far one way or the other. 3/ Using NONE , I still see a 0.5 drift in x with each rotation. Y seems correct. Certainly a great improvement. Lanczos seems well behaved to the extent that is has the same minor defects as cubic. Thanks for fixing non-int , looks a lot better.
hmm, still some very small drifts on lin/cub/lancz . If I create at the centre of a blank canvas a 10x10 "circle" - actually a stepped octogon - and rotate 6 x 15 degs it drops precisely one pixel. This will enevitably be contibuting to the spreading of the graphic itself and hence adding some blurring. More importantly NONE is behaving badly. It girates about some slightly off-centre point and ends up +4px in X after the 6 rotations. There is heavy and asymetrical distortion of the basic shape. Clearly any distortion should be symetrical. This again probably comes down to an offset, although apparently larger, which fairs badly due to crudity of nearest neighbour "interpolation".
Isn't this covered by bug #410066 already? In my opinion we should close this as a duplicate and get it off the 2.4 milestone.
*** This bug has been marked as a duplicate of 433436 ***