Hi, all

I'm working on a patch which shifts the rotation grid so that a grid intersection always falls on the center of rotation. The simple use-case for this functionality is when doing a corrective rotation in a photo with a clear horizontal or vertical object. Maintaining an intersection on the center of rotation means that you'd _always_ be able to stick the center of rotation on one end of the straight object, align a gridline along the object, and be done. Currently, this is not always easily doable without futzing with the number of gridlines.

My current rough-draft patch (against r28237) is up at: http://ocaml.xvm.mit.edu/~xsdg/stuff/gimp/shift_rotate_grid.v2.patch.txt

At the moment I have a few questions:

1) Let C be the coords for center of rotation, and TC be the coords for the transformed center of rotation. At times, it seems like TC is up-to-date and C lags (such as when dragging the center of rotation with the mouse). But other times, C is up-to-date and TC lags (for instance, when adjusting one of C's coords with the spinbox in the dialog). This makes it incredibly difficult to make the offset always correct.

I think this happens because gimp_transform_tool_grid_recalc() and gimp_transform_tool_transform_bounding_box() need to be called in differnet orders depending on where the canonical center of rotation coords are stored (C or TC).

When you update the spinbox, the gimp_transform_tool_motion() callback calls gimp_rotate_tool_motion() (which sets C from the values in the spinbox), and then gimp_transform_tool_recalc(), calls ..._grid_recalc() and then ..._transform_bounding_box(). So, in this case, TC will be stale at the point when ..._grid_recalc() is called (since TC is updated from C in ..._transform_bounding_box()).

When you move the center of rotation by dragging it with the mouse, however, it seems that sometimes ..._transform_bounding_box() is called without an accompanying ..._grid_recalc() call, which means that C is stale but TC is up-to-date. In particular, when this happens, C is temporarily set to the center of the image, which I find incredibly confusing. I'm not sure how or why this happens. Any suggestions for how should I fix this behavior so that it's correct in either case?

2) I want to only enable shifting when we're doing rotation (as opposed to shearing or scaling, for instance). This is as easy as clamping x_off and y_off to zero in gimp_transform_tool_grid_recalc(). From that function, how do I determine if the transformation is a rotation?

3) The bounding box is drawn in a different function. I would like to avoid splitting the shift logic across functions (or duplicating it in both). Any suggestions on how to keep the bounding-box aligned with the grid (including the shift offset), but still allow the bounding box to work when the grid isn't being calculated?

4) Any other questions, suggestions, or feedback?

Thanks, --xsdg

gg wrote:

Omari Stephens wrote:

Hi, all

I'm working on a patch which shifts the rotation grid so that a grid intersection always falls on the center of rotation. The simple use-case for this functionality is when doing a corrective rotation in a photo with a clear horizontal or vertical object. Maintaining an intersection on the center of rotation means that you'd _always_ be able to stick the center of rotation on one end of the straight object, align a gridline along the object, and be done. Currently, this is not always easily doable without futzing with the number of gridlines.

My current rough-draft patch (against r28237) is up at: http://ocaml.xvm.mit.edu/~xsdg/stuff/gimp/shift_rotate_grid.v2.patch.txt

At the moment I have a few questions:

1) Let C be the coords for center of rotation, and TC be the coords for the transformed center of rotation. At times, it seems like TC is up-to-date and C lags (such as when dragging the center of rotation with the mouse). But other times, C is up-to-date and TC lags (for instance, when adjusting one of C's coords with the spinbox in the dialog). This makes it incredibly difficult to make the offset always correct.

I think this happens because gimp_transform_tool_grid_recalc() and gimp_transform_tool_transform_bounding_box() need to be called in differnet orders depending on where the canonical center of rotation coords are stored (C or TC).

When you update the spinbox, the gimp_transform_tool_motion() callback calls gimp_rotate_tool_motion() (which sets C from the values in the spinbox), and then gimp_transform_tool_recalc(), calls ..._grid_recalc() and then ..._transform_bounding_box(). So, in this case, TC will be stale at the point when ..._grid_recalc() is called (since TC is updated from C in ..._transform_bounding_box()).

When you move the center of rotation by dragging it with the mouse, however, it seems that sometimes ..._transform_bounding_box() is called without an accompanying ..._grid_recalc() call, which means that C is stale but TC is up-to-date. In particular, when this happens, C is temporarily set to the center of the image, which I find incredibly confusing. I'm not sure how or why this happens. Any suggestions for how should I fix this behavior so that it's correct in either case?

2) I want to only enable shifting when we're doing rotation (as opposed to shearing or scaling, for instance). This is as easy as clamping x_off and y_off to zero in gimp_transform_tool_grid_recalc(). From that function, how do I determine if the transformation is a rotation?

3) The bounding box is drawn in a different function. I would like to avoid splitting the shift logic across functions (or duplicating it in both). Any suggestions on how to keep the bounding-box aligned with the grid (including the shift offset), but still allow the bounding box to work when the grid isn't being calculated?

4) Any other questions, suggestions, or feedback?

Thanks, --xsdg

Hi,

I looked at this centre shift issue a year or so ago. You may be able to find it the archive.

I found accumulated errors were leading to the image tracking around a central point.

IIRC some improvement was made by someone else at that time but since these base transformations will "soon" be migrated to gegl it was deemed not worth improving the existing code base in this area.

I suggest you dig out that thread before investing too much effort.

Do you know more specifically when it happened or what the thread might have been called? I have (local) archives back to Feb, 2008 and didn't see anything pertinent-looking that you had sent.

--xsdg