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. /gg _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
