Reproduction steps:
–>The cropped area becomes misaligned and selects empty space while dragging towards either edge of the image.
There is something inherently problematic with crop+rotate regardless of camera model, file type, or embedded orientation information in exif –
I find that I can’t get the crop window to the left/right edges of the image. This effect is worse as h>>w (try tall& skinny vs square. It also shows this problem up/down if the crop window is h<w.
I can also drag the crop window to extend outside of the image, which shouldn’t happen:
(the crop box extending outside of the image can be triggered at various (not consistent) times by dragging the handle on the opposite side, rotating the image very specific angles, etc. I haven’t tracked them all)
Here’s the actual output of that crop:
I see similar artifacts when treating an initially h>w image (1-texas-theater-bishop-arts.jpg) in a similar fashion (rotate such that h<w and crop).
Neither of these files is Sony (Texas Theather is Fuji, the forest is DJI, both are jpg) and neither contains the orientation exif tag. Interestingly enough, I don’t get squashed output with these, perhaps because of the absence of the orientation tag, but the crop behavior within TPAI itself is dysfunctional.
@david.horita
I moved your post to this thread as it’s another issue not related to the other one. The development team will work on these separately.
