Anyone notice big difference in final image brightness between PL6.1 and PL6.2

I upgraded in the middle of editing a gallery and noticed my images seemed darker and I was bumping exposure up maybe 0.5 stops or more to adjust compared to what I had been doing earlier in the gallery. So I exported a previously edited and exported image with exactly the same settings, and yep. The result is much darker… No edits in between. (note I never installed 6.1.1, so the original is 6.1 and the new is 6.2.

Anyone else seeing this with 6.2?

PL 6.1

PL6.2

No difference in brightness, but I see a difference in color balance!!! On the left, exported with 6.0, on the right exported with 6.2!

I have tried different photos, and it only happens in some: most are absolutely identical between 6.0 and 6.2.

What’s going on??? Repeatability of results is going to hell with every new release!

They are always poor at maintaining constancy between versions but as said this is getting really bad.

At the moment it seems not to be a good idea to update to any minor version higher than the one is installed. I have not updated to PL6 and my 5.4 is still running.
sometimes it is better not to be the fastest, but the most productive :innocent: :star_struck:

I’m actually suspicious that 6.1 was the version that was rendering wrong as most of my images I needed to adjust -0.5 on the exposure tool. Now I’m setting them all back to zero to export with 6.2.

I’m actually thinking of going back to 6.1 to finish this project but not sure… this is frustrating though.

Testing all the DPL6 versions I have on my Mac, I notice the following:

  • DPL 6.0.0.24
  • DPL 6.0.1.25 ← slightly different compared to predecessor’s output
  • DPL 6.0.2.26
  • DPL 6.0.3.33 ← slightly different compared to predecessor’s output
  • DPL 6.1.0.34
  • DPL 6.1.1.38 ← slightly different compared to predecessor’s output
  • DPL 6.2.0.41

Tested on macOS 12.6.2 on 2019 27 in iMac.
Test image well within histogram boundaries.
DxO Standard Preset was used, export to JPEG (first std. option) output as sRGB.
Output files compared in Lightroom.

Differences were not discernible, but showed in the histograms upon closer inspection.

Addenda

  • Checking with Apple Preview: Differences were not discernible
  • Checking with Fast Raw Viewer: Output from DPL 6.0.0.24 had a slight green tint
  • Checking with CapOne v12: Differences were not discernible, once that previews were rendered. before that, C1 showed the same tint on the first image as FRV, which hints at a slightly different rendering used for the thumbnail of the JPEG files.

Apart from the different appearance of the thumbnail, output of the different versions of DPL on Mac was close enough to be acceptable. Caveat: Other tests might show other results.

Mike, which computer and OS?

I’m running windows 10 on a Ryzen 5900HS based laptop with a RTX3070 GPU.

Camera is a Sony RX10 IV
(A beast of a bridge camera.)

Using DxO Wide Gamut?

The DxO Standard preset engages the DxO Wide Gamut working colour space. All images were exported to sRGB though.

Output might be different when other presets are used…but I’m not going to search for the one that hurts most. Maybe @MikeR could attach a file plus .dop sidecar so that we can see if and how differences show on our screens.

1 Like

I’m not surprised you saw some differences. Bug fixes and other improvements can affect the formulae for color rendering, exposure, optical corrections, and tonal balance. Hopefully for the better, but when we get used to a certain way of compensating for what PL does automatically then change can be disruptive. How can this be avoided? I wish DxO would give more detailed release notes, but other than that I don’t know what can be done. I’m aware of some bugs that have been fixed since PL6.0 and others that haven’t been fixed yet. So there’s probably more to come. It doesn’t bother me, but if this bothers you I recommend not updating the software until you’ve finished a project.

I don’t accept that upgrading from 6.1 to 6.2 should result in a half stop shift in exposure. It means you may have to completely re-edit your old work if you ever want to go back and work on something you did with a previous version.

I’ll post a sidecar and raw a little bit later on.

agreed, but as you can see in my post above, I see no such shift in DPL on Mac. In order to proceed with debugging, please attach one of your RAW files and the corresponding .dop file,

Raw and sidecar for the previously posted image.

2023-01-02 15.14.17-01 DSC-RX10M4.arw.dop (10.0 KB)
2023-01-02 15.14.17-01 DSC-RX10M4.arw (19.9 MB)

Thank you @MikeR , I’ll have a look at them later today.

@MikeR I couldn’t test this before because I needed to revert one of my machines to PL610, so one clone SSD and a partial “oil” change (uninstall and install) and I was able to test!

@sgospodarenko The installation for the reversal followed an OS uninstall of PL6.?.? and the install encountered 2 unexpected directories which needed to be removed manually, others may or may not encounter this problem!

So this is your image PL6.1.0 versus PL6.2.0, 100 percent JPG

and they are definitely different and it is not the only difference! There appears to be some meta data differences as well but that might be my fault so I will check!!

@MikeR What I messed up was the fact that your image and DOP existed in 3 directories MikeR (the BaseLine), MikeR\6-1-0 and MikeR\6-2-0! I ran the PL6.1.0 test correctly but ran the PL6.2.0 test on the BaseLine MikeR image and DOP!

Re-running it correctly produced the same results and in both cases the Metadata is different and also there is an XMP sidecar file being created by PL6.2.0!

I deleted the sidecar file from MikeR before re-running the tests! The sidecar contains the following and I don’t really know why it has been created for one case but not the other (or at all) please see below for the explanation of this part of the puzzle!?

Sorry:-

The metadata part is my fault with respect to different ‘Preference’ settings between the two releases on my two machines (oops)

PL6.1.0 was set up as

so the metadata was taken from the DOP when DxPL “discovered” the image and DOP but

PL6.2.0 was set up as

so the metadata was taken from the image when DxPL “discovered” the image and DOP (i.e. there was none available) and the sidecar file is no longer automatically created!

So part of the mystery solved, operator error sorry!

UPDATE:-

I repeated the cloning exercise and upgraded to PL6.1.0 to PL6.1.0 on the new cloned system and found the following comparing PL6.1.0 with PL6.1.1

But comparing PL6.1.1 with PL6.2.0 produced

So, providing I haven’t got anything else wrong (fingers crossed) the change occurred going from PL6.1.1 to PL6.2.0, i.e. the change was “introduced” with PL6.2.0!

@MikeR , with your image and sidecar, I get three distinctly different groups of images and histograms.

  1. 6.0.0.24
    Bildschirm 2023-01-16 um 22.04.11

  2. 6.0.1.25…6.1.0.34
    Bildschirm 2023-01-16 um 22.04.30

  3. 6.1.1.38 and 6.2.0.41
    Bildschirm 2023-01-16 um 22.04.47

Moreover, I find differences in what is written as colour space/profile related metadata…but only in 6.0.0.24: Metadata Archive.zip (39.8 KB)

If we dismiss 6.0.0.24 as an initial-no-good release, the rendering difference came in between versions 6.1 and 6.1.1. Again, all of the above is on Mac.

@MikeR, you’re on Windows?

Shouldn’t changes of this type between versions been identified in the release notes? Seems to be more than just a “tweak” from what I can see here (I’ve not checked the images myself though)

Yes I’m on Windows as I mentioned before (with more details).

So it seems two others are independently confirming what I see.
Good to know, but also concerning. I’m currently traveling and don’t have images from another camera. but I wonder if one of you guys can copy all edits from one of my images and paste onto one of yours from a different camera (maybe even a not-Sony camera since this one was a sony) and see if it’s specific to this camera or this RAW file?

I’m curious if the issue is happening early on in the image decoding or later on in the processing pipeline. From my perspective it really doesn’t matter, but would be good information for whoever is going to try to figure out the root cause.

@sgospodarenko or @StevenL Any comment?
Mike

1 Like