> 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
>> My current rough-draft patch (against r28237) is up at:
>> 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
>> 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?
> 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.
Gimp-developer mailing list