3976 x 3973. Same as it was.
Okay, I get that too. Strange effect to adjust the crop with a PC though. Dragging corners can fix the ratio, but I usually have to drag two corners to make it work.
Anyways, the crop numerical issue is not new, but it pops up every now and then.
Lr shows the same slack, so I suppose that itâs an accepted ânot quiteâ.
I donât know if I understood you well but it changes vertical.
George
Just for the record, youâre still not getting it.
Which leads me to ask, what exactly, in your opinion, am I not âgettingâ?
Rounding is a mathematical fact.
Take a right angled triangle with a vertical side of 300px, the horizontal side of 400px and the diagonal of 500px.
Reduce the vertical side by 1px and alter the other two sides to maintain the same proportions.
So, the base side becomes 399px, but the hypotenuse becomes 498.6px
Now, rotate the triangle so that the hypotenuse becomes horizontal, but how do you represent its length as an integer? What number are you going to put in the âwidthâ text box?
And the height from the now horizontal hypotenuse to the apex becomes 239.27194. What number are you going to put in the âheightâ text box?
What do I need to âgetâ to ensure that I only end up with whole numbers in the crop dimension boxes? How would you do it?
1 Like
You drew me back in. You crop an image to X by Y then export. You get X by Y pixels. The only floating point stuff is in figuring out what to put in X by Y pixels. X and Y are integers throughout.
That might be OK for simple scaling, but we were also talking about rotation, which changes everything.
No, look at my statement. The rotation only affects the âwhat to putâ bit.
Nope. Not getting it. The crop rectangle is, essentially, two right-angled triangles joined by the hypotenuse.
As soon as you rotate that rectangle, even without resizing it, the bounding rectangle to contain the rotated rectangle has to get bigger.
The Rotated rectangle is exactly the same size as the Original - on the rotated axes. But, as you can see, in unrotated coordinates, it occupies significantly more space.
It is during the translation from rotated to unrotated that the floating point inaccuracies are introduced.
More space in the original image space. Not in the output.
`Please explain better. What you just wrote doesnât make sense to me
@zkarj , @Joanna , why not try to talk instead of doing the forum-pingpong?
You can exchange connection possibilities in PM⊠FaceTime? Other?
Better yet, Iâm off to Asia for 3 weeks, with PL9 in tow.
I donât know how to explain it better. My post beginning âYou drew me back inâ is as concise as I can get it.
As I understand the issue:
The floating point calculations do their magic, then the floating point result must be forced to fit an integer number of pixels for each dimension.
The most âaccurateâ representation results in integer values that are different than the user specified ratio.
So what is PL to do?
Should the algorithm output the result as-is and let the user decide how to adjust, or should the algorithm choose a âcorrectiveâ action to perfectly match the user specified values.
Then, should this corrective action add/remove pixels from the edges or should the included pixels be expanded/compressed to get the exact desired ratio. The choice then affect how diagonal lines or edges in the photo are shaped.
As I read this thread,
@Joanna seems to prefer the current method that requires action by the user to manually adjust the ratio. She shows two ways to manually make this adjustment.
@zkarj seems to prefer that the algorithm automatically make the adjustment.
Is this a correct summary?
The control freak in me wants to control this output manually. But if batching a bunch of photos, the automatic method is probably adequate.
If so, perhaps a suggestion to DxO would be to add an on/off toggle in the crop section to do this and allow the algorithm to decide the method based on the transformation.
Sigh. WHY are floating point numbers needed â at all â to choose an output rectangle?
This really is it. Iâm leaving home in a few hours and wonât be back for nearly 3 weeks. As of this moment, Iâm unfollowing this thread. Itâs exhausting
How else would you make calculations? The examples where used here where for a simple 1:1 ratio. But I asked how that would be with a ratio of 16x9. I didnât get any answer yet. Using a 1:1 ratio can cause a deviation of 1, using a ratio of 16:9 can cause a deviation of 144!
Rounding errors are all over the image itself. Itâs impossible to draw a straight line that is not parallel to the sites of the sensor, going along the columns and rows.
George
1 Like
Another approach would be to have the crop window that has only values that meat the crop ratio so 16x19,32x38,64x76 etc. Nothing between.
George
1 Like
Have a good time! Thereâs more to live than PhotoLab and FLOPS,
although FLIP-FLOPS can be quite welcome 
1 Like
I think thatâs what @zkarj is meaning.
George
If integers were used, the rounding would take place anyways, leaving squares non-square.