Changed behavior on 6.3: cropped image not automatically maximized after cropping

When I crop an image in version 6.2, which is ‘maximized’ in the preview window, it’s stays maximized after the crop.
In 6.3.1 however, after a crop the picture is not maximized and I need to use the scroll wheel to maximize it in the preview again. This is somewhat tedious (as I want to view all of the cropped picture), and I hope it is a new setting in 6.3.1 which I can change to get the same behavior as in 6.2 and before.
Any suggestions?


PL 6.3 introduced a change to the crop function. When you activate the crop tool, the zoom changes to show the whole area of the image in the image viewer window. When you deactivate the crop tool, the zoom returns to whatever it was before. My understanding is that DxO made this change according to user feedback.

Is this the behavior you’re talking about? There’s no setting that I know of that will revert to the former behavior. It seems to me that the new behavior isn’t even mentioned in the user guide or release notes.


I see the same behavior and I don’t like it.
I think it’s a bug because the rotation tool doesn’t do this and it also can change the image size.

Also if you are using the “maximize zoom” option and click into the crop tool, the image is reduced to fit the whole h cropped image. If you change the crop and then deselect the crop tool the magnification doesn’t return to maximized zoom. But if you don’t change the crop, it does.

This can only be a bug, not desired behavior. There is nothing logical about the inconsistencies between how the crop tool operates if you do or don’t crop and how the rotation tool operates.

I hope it’s fixed in 6.3.2 or shortly thereafter.


Yes, I see what you mean with ‘whatever it was before’. For me not very logical (but who am I ;-), because when I make the crop bigger, I don’t see the whole crop after pressing the crop again. Have to zoom out to view the image…
I would prefer to keep the (cropped) image maximized in the view window. I use a 4k monitor btw, maybe that is partly why I notice it, and not all users encounter it.
Strange thing is when I make the crop very small, it seems to do some zooming after pressing the crop button.

1 Like

Yes - I find this very tedious too … It requires an extra/redundant step after just about every crop.

I also recall someone raising this with a DxO staff member during beta testing - and the response was along the lines of “We’re looking into it” … … So, here’s hoping it will revert in an upcoming update.


The behaviour you describe was a Mac/Win difference I mentioned here.

Disappointing to hear that they’ve implemented the Mac behaviour on Windows since what zoom level a user wants to crop at is entirely down to user preference. I hate this auto-zoom, and no other tool that I can think of is coupled to the zoom level in this way.

Every time they change something like this with no option to retain the old behaviour they just make a new group of people unhappy.


I guess it’s this release note for 6.3:

• It’s now possible to see the whole image without constraint when using the crop tool.

Of course, it was perfectly possible to see the whole image before too, and I could crop at the zoom level I’d chosen without the crop tool deciding it wasn’t big enough. I guess “No longer respect user’s zoom level when using the crop tool” didn’t sound as good though. :roll_eyes:


I hope DxO is reading along here. Or do I need to report this as a bug?

As I reverted back to 6.2 I also noticed all edits done with 6.3. are not ‘read’ by 6.2 (seems to ignore all the .dop files…) So I have to redo all changes I did with 6.3. Almost looks like a big change was implemented on the .dop file structure, making it no longer downward compatible…


It’s worth reporting, if for no other reason than to show DxO that there’s user feedback against their random changes as well. I opened a case on the Mac behaviour some time ago, but clearly my user feedback didn’t have an impact.

1 Like

Yes - that’s expected behaviour, Paul … All versions of PL will ignore sidecar files from any later version - as a guard against parameter incompatibilities and/or new features (that the earlier version knows nothing about). That is, backwards compatibility is a given - but forwards compatibility is not.

No - it’s much simpler than that.

The way PL checks for sidecar compatibility is via a Version # setting in the .dop file.
For example, here’s the Version details within a sidecar created/updated by PLv6.3

  • If you were to change that (with a text editor) to 17.0 - then you may find that PLv6.2 reads it OK.
  • No guarantees tho - and I recommend making a backup before you change it.

John M


FYI: I have raised a request at DxO Support (20th feb). No response yet…

@John-M thanks for your extensive answer!


1 month later, 6.4 is just released, with still this awkward behavior when cropping… And no response whatsoever from DxO. Disappointing…


Actually the behavior in 6.4 is different but still not correct…

Now when you leave the cropping tool, the image fits to the window as it did in previously working versions (before 6.3). The problem is this is still not “fit to window”. It returns to the correct zoom for that image, but that zoom level (say 30%) becomes fixed… and changing the image to another (larger) image, doesn’t cause the zoom level to fit again…



1 Like

I do NOT like at all, that leaving something with ESC to be applied, e.g. the crop in this case.

The general behaviour of ESC is to leave things untouched !!

1 Like

This has been raised before - many times.

@Cecile-C any chance you can raise this to the top of the pile as a priority?

It is a totally non-standard and unexpected behaviour.


@Joanna Hello Joanna, thanks for driving my attention on this topic. This issue is identified and added to our list, but not for the current version. It will take a bit more time to fix it.

1 Like

Hi Cecile

Thanks for the acknowledgment. But a lot of us are quite concerned about the length of “the list”.

1 Like

It sounds like v7 or more!

I just did a quick search and found a post on the Optics Pro 10.4 beta forums that mentions this issue…

In 2015 !!!

1 Like

It sounds like well past v7 maybe 99