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