[Gimp-developer] Shifting rotation grid with center of rotation: need help/feedback

[Omari Stephens]

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