Crop not always exactly the right aspect ratio

DxO PhotoLab
1

Photographing with a high resolution camera gives me the option to crop my photos if I so desire. And I crop quite frequently when I think that improves the photo.

When applying a crop to my photos I always choose the option to keep the original aspect ratio of my camera, which is 2 : 3. In PhotoLab 8 I always select the “3x2” aspect ratio to make sure that the photo has the same aspect ratio as my camera.

Since I started using PhotoLab (shortly after the introduction of version 8) I noticed that, after cropping the photos in the way described above and exporting them, some of the photos are slightly larger at the short side op the photo.
In other words: After cropping with the “2x3” aspect ratio and exporting the photos the short side is not always exactly 2/3 of the large side of the photo.

I’ve noticed that when I closely watch the changing dimensions below the photo while cropping and make sure that the horizontal dimension is exactly 1.5 times the vertical dimension (say: 7200 x 4800) the exported photo will be exactly 2 : 3. If not, the aspect ratio of the exported photo will not be exactly 3 x .

It would be nice if I didn’t need a calculator every time want to crop my photos to make sure that the exported photo is exactly the aspect ratio that I selected when I cropped the photo.

I never had this issue with Lightroom. When selecting to force the cropping to the 3 : 2 aspect ratio, the exported photos would always be in that aspect ratio (the large side of the photo is 1.5 times the size of the short side of the photo).

2

This has been mentioned more times. The reason is probably the optical corrections.

George

3

This is due to integer division rounding and to be expected unless the software does a recursive division until it achieves perfection.

My Nikon D850 has a sensor size of 5504 x 8256

If I crop the short side by ⅔, I get 3669.3̄ (recurring). Rounded to nearest neighbour, that gives 3669.

If I crop the long side by ⅔, I get 5504 (as expected for a 3 x 2 sensor)

Both results are perfectly accurate but, since it isn’t possible to start splitting pixels, it is a mathematical reality.

In reality, I just tried resizing a 8256 side to 5504 and found the shorter side ended up at 3670.

Now, 3670 x 3 / 2 gives 5505 exactly, whereas 3669 x 3 / 2 gives 5503.5.

But, although the toolbar for the reframing tool shows 5504 x 3670, the reframed size on the metadata palette shows 3669 x 5503.

The truth is, that for certain integer divisions, there is no way you can ever get a perfect ratio. Why? because what we regard as division uses floating point numbers (some of which can end in a recursive decimal part), instead of integers. And you can’t go about chopping up pixels to get precise ratios.

You will, more than likely, find that Lightroom is simply using a recursive division to force the numbers.

Not forgetting to mention that my Nikon D850 sensor measures 35.9mm x 23.9mm and ⅔ of 35.9 is 23.93̄ (recurring). So, even the sensor isn’t an exact ratio.

Anyway, why is 1 pixel really all that important?

2 Likes
4

I would welcome a feature that adds an option to the cropping tool that, whenenabled, would snap the crop to the nearest ‘correct’ amount of horizontal and vertical pixels based on the selected aspect ratio (except maybe for ‘original’, because not all sensors have a perfect 2 x 3, 3 x 4 or whatever aspect ratio).

1 Like
5

As I have demonstrated, even if you start with an “original” of 3 x 2, it is impossible to guarantee that any given scaling will match the same ratio in both axes.

And you need to answer the question - what difference does one pixel make in the scale of a few thousand?

1 Like
6

How is that impossible? You offer 2x3 pixels, 4x6 pixels, 6x9 pixels, …., basically just even numbers on the short side for 2x3, just skip the odd numbers of 3x4.5 pixels etc. The crop grid could just snap to those numbers. Not so complicated.

As the long side is always 1.5 times the short side, an even number on the short side guarantees a whole pixel on the long side. For some other aspect ratios it does not work so well, there would be bigger gaps.

One pixel difference can be very important. If I need pictures for an e-commerce website, and some of them are 1 pixel higher then others, and I am scrolling down dozens of products, the difference will add up and screw up the whole design. Why not being exact if it is possible?

1 Like
7

One more thing: Drag the crop frame by its corners for better accuracy in respect to the ratio. And if you keep the short side at even numbers, results should be perfect.

Be careful with export: The targeted size can introduce split pixel errors again!

3 Likes
8

I will keep your tip in mind next time I’ll be editing my photos and see if the end result, the export to jpeg, has actually the right horizontal and vertical dimensions.

But still having the option to have the crop snap to the nearest correct dimensions based on the chosen aspect ratio would be a welcome addition to an otherwise good piece of software.

I’m doing all the editing of my concert photography in PhotoLab 8 and have found it to give me better and faster results than Lightroom. Getting the exact aspect ratio is one of the few things I found that could be improved…

9

And there’s your problem. Try it with 5 x 4, 5 x 7, or 6 x 17. It soon starts to get complicated.

You also need to take into account the pixel size of the image when it is exported, possibly at a smaller size than the cropped pixel size.

Say you crop my full frame 5504 x 8256 image, in proportion, to half its dimensions - 2752 x 4128. Now, the finished exported size needs to be 2048px on the long side at 2 x 3 proportions.

The long side of the crop is 4128, which is 2.015625x the required length after cropping.

Now, take the short edge and divide it by 2.015625 to get the required cropped size before exporting. You end up with 1365.33333 pixels.

So, even though the cropped size would be whole pixel dimensions, by the time it gets exported, they would end up being fractional at 2048 x 1365.33333 and all the precision invested in cropping would be lost

1 Like
10

Indeed…and the initial crop size does not really matter, iff it has the correct aspect ratio. The magic is in the export: as you say, at other ratios, things are a little bit more involved: If the ratio needs to be AxB , sides must be integer multiples of A or B respectively.

Now, if the long side is your target (which is often the case) and the short side needs to be in perfect ratio, you’re cooked, e.g. with sizes like 1024 or any other M**n number…except for 1x1 or 1xM and a few select ratios maybe.

Or something like that… Good luck

1 Like
11

If the long side of the crop in pixels devided by the largest number in the aspect ratio (with a 3 x 2 aspect ratio that would be 3, with 4 x 3 that would be 4) the result would be a whole, non-fractured number. The short side of the photo should then automatically also be a whole number and the resulting crop would be the exact aspect ratio.

Since the editing and cropping of photos is done on a computer and computers are particularly good at calculations, I’d much rather have the software do these calculations for me. Hence the suggestion of an added feature.

12

I’ve shown in the past that it often gets a 1:1 crop unequal. That maths is pretty basic. X = Y.

2 Likes
13

I completely understand your request. Having that feature would make the handling easier…but would still produce errors due to rounding as @Joanna mentioned above. Input and output pixels are located in discrete positions and scaling down an image will, im most cases, introduce aspect ratio inaccuracies due to rounding. Most apps hide that fact though.

14

Even the sensors themself have faults.
Nikon D700 4256x2832. Not exactly 3:2. In parentheses the corrected value after optical corrections have been applied.
afbeelding

afbeelding

afbeelding

afbeelding

afbeelding

None of them are exact. The crop values are lens dependent.

Cropping is a calculation with rounding faults as explained by others.

I still don’t know what 1 pixel can make a difference.

George

15

Aren’t these image not shown in a predefined space with fixed values?

George

16

I can imagine use cases where 1 line of pixels matter,
but then, PhotoLab is not the tool of choice!

17

I don’t know any. Except maybe for some scientific stuff.

George

18

If you are assembling images next to each other, a missing line of pixels will show.

Sorry, but this is not true. Computer calculations like these are done using floating point numbers, to allow the code to choose which way the result of a division gets rounded (up or down).

@vtpeters I just wrote a code snippet that demonstrates that 4 / 2 does not equal 2…

Capture d’écran 2024-12-01 à 11.21.56
Capture d’écran 2024-12-01 à 11.21.561732×1470 369 KB

Which looks odd until you realise that the compiler works with binary values. So, if I ask the debugger to show me the two values as binary…

Capture d’écran 2024-12-01 à 11.46.14
Capture d’écran 2024-12-01 à 11.46.14840×118 21.8 KB

… you get to see that there is one bit, somewhere in the middle, that is different, proving that 4 / 2 does not always equal 2.

Now, if you want PL to calculate rounded values, do you want it to calculate using upwards rounding or downwards rounding and to how many significant digits?

Questions, questions, so many questions to ask just to get to what you perceive as a “simple” answer :wink:

@vtpeters Tell me - how do you calculate manually to overcome this shortcoming?

19

Like making pano’s. No problem.
I’ve been watching how they photographed the Nightwatch of Rembrandt. A complete scaffold was build in front of the painting exactly parallel to the painting. Camera on rails and making pictures of part of the painting. There I “can imagine” 1 row of pixels might be important. But even here I’m not sure.
It resulted in an image of 717 Giga pixel, file size 5.6 Terrabyte.
Have a look how deep you can zoom in. Ultra high resolution photo

George

20

Can you imagine something like this being done in the USA? Ain’t no way funding would ever be approved if public money were involved. Thank goodness Europeans have an appreciation of art for art’s sake!