BUG: Crop ratio and resolution rounding errors

I have a 2x1 crop selected and when I export the image I need to resize it down to a lower resolution. What I want is 2160 x 1080. In the export, if I select “make shortest side 1080” then I get 2159 x 1080. If I select “make longest side 2160” then I get 2160 x 1081.

Also of note, the actual pixel size of the crop selection is displayed as “2025 x 1013 px (2 x 1)”, which of course is not perfectly 2 x 1. I’m not sure if this is where things go wrong, or if it’s on the export scaling operation.

meanwhile you can simply install a free Image Magick app ( ImageMagick – Convert, Edit, or Compose Digital Images ) and export to a command file (.BAT) with one line like ( MS Windows example, you might need full path to executable )

magick.exe convert %1 -quiet -resize 2160x1080! %1

instead of exporting to disk, that will give you exactly 2160x1080

Thanks for the reply!

The main thing I’m trying to do in this workflow is split a 2160x1080 into a left and right 1080x1080 to make an image you can pan across on an IG carousel. I have been doing this by hand in Affinity Photo. Does the app you mention have parameters to be able to do something like this? I.e. one image in, two (left and right) out?

do you mean to split one image in to two images ? one exactly left side of the original and one exactly right side of the original ?

Yes, exactly that. I will check out the link. Thanks again!

for 16-bit TIFF output MS Windows .bat file might be like this

magick.exe convert %1 -quiet -resize 2160x1080! %1
magick.exe convert %1[0] -quiet -crop 50%%x100%% %~n1%%d%~x1

[0] - to operate only on actual tiff image, it also has a preview ( [1] ) , so w/o using [0] you will get 2 + 2 , instead of 2 files )

PS: you can naturally dump to .jpg there you do not need to bother about embedded preview in tiff

I actually installed the linux version in WSL so I’ll play around with it some more. But your command will definitely get me pointed in the right direction. And yes, I’d like to do TIFF input and JPG output. I’m not clear on what the embedded preview is exactly, I’ll have to check that out.

if you output to tiff you have like in raw : image + preview ( so 2 images ) … [0] selects actual 16bit image inside tiff to operate on for splitting in two ( left + right ) parts

Ah, gotcha, thanks for that clarification!

then you can simply replace

magick.exe convert %1[0] -quiet -crop 50%%x100%% %~n1%%d%~x1


magick.exe convert %1[0] -quiet -crop 50%%x100%% %~n1%%d.jpg

image magick will understand that want to convert splitted parts of the tif into jpg files

PS: you can add -quality option to control JPG output quality

magick.exe convert %1[0] -quiet -crop 50%%x100%% -quality 100 %~n1%%d.jpg

PS: why - if works as well directly in Windows…

For desktop I’m exclusively a Windows user but for command line tools I find the Linux environment quite convenient. With Windows terminal I always have a powershell and Ubuntu tab open. In this case I was able to install the tools, read the man pages and execute commands all from one window and without ever touching a mouse. The Ubuntu window operates on my windows directories so there’s no hiccups in the workflow.

That said I have just recently read about the export to application feature in PL (new PL user) so it may make the most sense to install the Windows version if the batch file can be executed directly (then again you could just as well make a .bat with a wsl.exe invocation of the unix tool).

In the end I probably just find it fun to explore different environments, helps keep my unix skills up.

Is that the file size from an un-cropped image - or, is it the result of you cropping the image ?

  • If the former then that’s unusual - what sorta device would produce that file (?)

  • If the latter; is that the result of you cropping “free-handed” or have you used PL’s 2x1 crop preset ?

Note: I’m asking these questions as they may explain why you’re getting those NQR ratio numbers in the first place.

Either way, what you’re calling a crop-ratio rounding error seems correct to me; PL is dealing with these NQR input-crop-sizes and producing results within the limits you have prescribed,

The raw image is 8256x5504 (Nikon Z8). I then picked 2x1 and used the mouse to drag my crop rectangle and those are the dimensions it shows me for the selection I made.

It would seem the software either needs to adjust user selections to exact 2x1 dimensions (e.g. 2026x1013), or, internally track decimal points (e.g. 2025x1012.5) so that it has the precision required in later steps to achieve a perfect 2x1 on export.

1 Like

with a pile of bugs and requests that DxO has to deal with ( which is growing every day, higher and higher, much faster than DxO can possibly deal with as we all see ) it is as noted above much easier to let it go and just export to app that does it all ( resize and split ) better and fully automatically

Even then you are not guaranteed 100% accuracy.


I’m certainly not waiting around on a fix, and I appreciate the workaround provided, but as a software developer myself I believe all bugs should be reported with sufficient detail so that they can be added to some kind of backlog.

1 Like

It’s not a bug. It’s math.


1 Like

Hilarious, but no, you haven’t read what I’ve written if you think that. When a user picks 2 x 1 as their crop ratio and the resulting crop ends up not 2 x 1, what exact math principle suggests this is correct?

1 Like

Changing the size based on a new length of 1 size will be done by a factor original length/new length. That number will be used to calculate the new other size. There is no relation with the other edit: the crop. Resizing is not part of the crop.
What you want is that the new second size is calculated out off the first size based on the crop ratio. But even if that is done, one has to start with the shortest size.
A crop ratio is not only 1x2. What if the crop ratio is 2x3? How will you get exact numbers then?