Cropping: Square not always square

I can’t reproduce it.


Thanks. I suppose this is good news. I’ll just have to keep a careful watch on the dimensions when cropping square.

To make a quote, select the text in a message - it pops-up a quote box.

Hey guys. I think I might have found a possible cause.

Using macOS Ventura - PL 7.7.1

If I resize using the corner handles, the pixel ratio seems to stay equal. However, if I use the side handles, this seems to provoke a difference, especially the left side. But then using the corner handles seems to put things right.

More easily provoked at smaller crop sizes.

Just tested this while you typed…and got the same result: non-square “squares”.

This issue has been around for quite some time. Nevertheless, DxO seems to have wanted to fix more pressing issues than this one…

OK, thanks.

After some extra testing it seems that I can’t replicate it either. Interesting. I’ll keep testing.

I found a turn-around in DPL 6:

  1. The image must be initially in unconstrained ratio.
  2. Crop it to a rectangle with the smaller side at the final dimension you want.
  3. Apply the aspect ratio, 1 x 1 for example.

And voilà: both sides are equal by ± 1 pixel to each other and to the set dimension. Yet you must not change it because the result will be erratic.
I did it first on a non edited pic then I applied perspective and horizon changes and tried again: it works just as well.
I can’t tell if it works with DPL 7.


You can deform a square in the following way too:
(1) On a fresh image, no corrections, use 1 x 1 crop to select some square.
(2) Close the crop tool.
(3) Use the Horizon slider.

If you skip point (2) above, the horizon slider is applied before cropping, and then you will get a perfect square (which is however larger for some unknown reason – at 45 degrees it’s larger by a factor of 1.316, which is almost equal to fourth root of 3, but that’s probably a coincidence).

If you want to keep 1 x 1 aspect ratio

  • Don’t use Horizon, Perspective, or Volume Deformation tools on a cropped image, unless the Crop tool is active.
  • Don’t use Distortion tool with unchecked ‘Keep aspect ratio’, unless the Crop tool is active.

That is fascinating stuff. Thank you for pointing that out.

Somehow, I have fallen into the habit of always keeping the crop tool open whilst manipulating the proportions, etc. So maybe that’s why I haven’t found the problem. That and the fact that, for printing, a couple of pixels on an A2 print really doesn’t affect the finished result.

If you do it in the “right” order, you should be safe. But if you want to level the image differently or apply other geometric corrections on a cropped image, which may happen to anyone, activate the crop tool first.

I couldn’t reproduce it on PL7.7.2/Win11.

I was not able to recreate the problem on my Win11 system trying various techniques described.
Wondering if anyone with the problem has tried @mwsilvers suggestion to reinstall/repair the PL7 software and or submitting a support request DxO can attempt to address the issue? If not a quick fix perhaps this can be resolved for PL8. Thanks!

My example was produced by only dragging corner handles.

In my experience, dragging a 1:1 crop more often than not will show unequal dimensions at some point in the drag, though it is less than it used to be.

The silly thing is… if the resulting image were off by a pixel or two, I wouldn’t know, but because the numbers are displayed for me while dragging, it bugs me!

Poor analogy, Joanna, because no speedometer in any cars is meant to be exactly accurate. This is different: PhotoLab seems to suffer from rounding errors in an area where LightRoom Classic, Photoshop CC, and ON1 Photo Raw can calculate without a rounding error. If a product sells me “square,” then height and width had better be the exact same number!

The excuse that it’s not noticeable is really rather lame because most of the things PhotoLab is supposed to be so much better at than the competition are not noticeable in finished photos either unless one is pixel-peeping, and if you are pixel-peeping, then you bet one pixel makes a difference!

It always amazes me that for some people, DxO can do no wrong, and if they do, it doesn’t matter because it’s not noticeable…

I don’t think it’s a matter of roundings. Then it should have been visible more frequently.


Firstly… while 1 pixel won’t be noticeable in a print, it can create weird artefacts when used digitally. A fine white or black line along one side of a photo is very noticeable. If you put an image in a square frame in software (including browsers), that frame will be perfectly square.

Secondly… when it comes to software, a preceived problem is still a real problem. 1:1 is a very precise definition, not subject to rounding. When I see numbers on screen that aren’t the same, it doesn’t compute. Yes, I understand rounding, floating point calculations and all that, but at that time I am a user drawing a square, not a software engineer.

If PL would simply make a special case for any ‘whole’ ratios (where one dimension is an exact multiple of the other) and just round it down to exact, then who are we to quibble that half or two thirds of a pixel was missed?