I must correct myself.
When initializing the crop tool it mentions “4256x2832 3/2”.
When selecting 3/2 from the drop-down list it mentions “4248x2832 3/2”. Exactly 3/2.
Playing with the sides or the corners doesn’t change that ratio in pixels in both cases.
George
I had not considered the zoom factor, as I generally always have it “to fit” when cropping. Unless I was cropping particularly small I don’t think I’d ever think to change that.
But still… while zoom may affect what sizes are achievable, all such sizes should adhere to the selected ratio. E.g. if zoomed to 50%, it would be reasonable that only odd or only even sizes would be achievable. But there is no reason for 1/1 ≠ 2600/2601
But this is the key to why you are getting these anomalies. Whilst moving a control point with the mouse, the pixel position is calculated in screen coordinates, which are the translated to relative image positions, which could well include fractional differences.
Considering the zoom factor only impacts the precision of the pixel accuracy.
Testing with 10% zoom i can only reach 10 pixel steps, but always an exact 1:1 ratio with the identical pixel size for height an width.
I am working on 27" with 1920 x 1080 resolution
I can replicate this ‘feature’ too.
Same behaviour if zoom to fit or 100%.
It is actually the opposite of this. When I drag the lower bound, I am adjusting a Y position and this will indeed be in fractional (or multiple) pixels at times. But I am not touching the X positions. When I drag the Y to a place on the screen, PL is giving me a rounded answer in whole pixels. Then it should take that rounded answer and simply X=Y. You may be right in that the rounding is occurring only for display and in fact my Y value is 2600.4 and the X position of the frame is such that it is on a half pixel which causes it to round UP to 2601. But this is the nub of the whole problem.
In the end, PL must come up with a whole pixel solution, and it should honour the ratio with whole pixels where possible. For a 1:1 ratio, this is always possible. Zoom levels, display scaling, mouse accuracy, et al are only responsible for which values of the dragged axis are possible to reach. The non-dragged axis is derived from a calculation where 1=1 and pixels have nothing to do with it. In a non 1:1 ratio, yes, some rounding may have to occur. For example in a 3:2 ratio if the height is not a multiple of 2 then the width will have a half pixel to deal with. But if the height is a multiple of 2, then there is always a perfect 3:2 answer and PL does not always deliver.
Here’s an example of exactly this, which only took me a few seconds to recreate by dragging only the bottom border of the crop frame. I made PL say 800 for the height. There is no other correct answer for the width than 1200, yet there you see 1201. To reiterate, I never touched the width.
Oh! And interestingly, while trying to prove the point that corner dragging does not suffer this problem… I discovered it does!! I carefully dragged the lower right corner expecting never to be able to reproduce the 1201x800 but in fact I just did.
This leads me to believe the problem is that the rounding is occurring only for display, and the real frame size is fractional. I suspect it is only fixed to integer values when applied, but even then the ratio is not respected. It should be respected at all times during the drag, even if it has to work in fractional values under the covers.
