Request: Enable PhotoLab to be backwards compatible with OpticsPro

Given that PhotoLab has replaced OpticsPro - with PhotoLab now being a “super-set” of OpticsPro - it should be possible to open a RAW file with PhotoLab, that was originally processed using OpticsPro, to find the identical correction results … such that rendering the same RAW image, with the same set of corrections (as originally recorded by OpticsPro) should result in an identical RGB image (eg, JPG, Tiff, etc).

Most unfortunately, this is currently not the case.

The key cause behind this lack of backwards compatibility (between PhotoLab and OpticsPro) is due to the lack, in PhotoLab, of a Smart Lighting mode equivalent to the OpticsPro mode = DxO OpticsPro 9

In conjunction with the related problem reported here; Smart Lighting has lost algorithm to process (purposefully) under-exposed images … this means that;

  1. it’s still necessary to retain OpticsPro, for efficient processing of certain “types” of RAW files (see the link above for more details) … and;

  2. One must be very careful NOT to open a RAW file with PhotoLab, that was originally processed using OpticsPro; else PL will overwrite database & sidecar files with correction details that are NOT necessarily equivalent to those originally achieved using OpticsPro.

Requested solution;

  1. Provide in PL the Smart Lighting algorithm that is known within OpticsPro as Mode = DxO OpticsPro 9.
  • It does not need to be called Mode = DxO OpticsPro 9 within PhotoLab (I fully understand why that would not be a good idea).

  • Instead, it might be named “Mode = Brighten” (or whatever) - and it could be sold/spruiked as a Smart Lighting feature that assists with processing of purposefully under-exposed RAW files.

  1. If PhotoLab finds a sidecar/.dop file from a previous version then it should NOT overwrite the file- Instead, it could, for example, save the original sidecar file with a different extension (say ~.dop_OP11).

Why not go a step further and introduce process versioning, as described in the given link? There will always be changes, which might also be introduced between PL1 and PL2 for example.

Even more sidecars is hard to handle. IMHO PL should use XMP instead of dop in the future. In the XMP an attribute should carry the process version the RAW was processed with. All correction algorithms should have an equivalent version. If a new major PL version is released, the algorithm assemblies are cloned and only the new clones are developed further, so that there is a SmartLighting_1 and SmartLighting_2 for example. If an old RAW is opened, V1 is applied according to the version in the XMP. On new RAWs V2 is applied as default, but the user can switch to V1 manually.

2 Likes

Hum!
I’m in holidays and I have no DxO access.
But, in my memory, if you open a “old” DOP11 in DPL1 you have a virtual copy with DOP11 corrections (not identical this is right) and a new “DxO Standard preset” new image.
When you reopen in DOP11, You have the first correction (DOP11) and a “DxO Standard preset” correction. DOP11 can’t read DPL1 section in the sidecar.
What I mean is sidecar.dop is a good way.

Pascal

Hi Pascal,

Unfortunately, when you open a sidecar/.dop file with PL it overwrites the original file, as was produced by OP … which then makes it unreadable by OP.

Furthermore, the new sidecar/.dop produced by PL can sometimes result in a set of corrections that do NOT faithfully replicate the original set as produced by OP … especially when the original used Smart-Lighting mode = DxO OpticsPro 9.

John

OK John.
I mixed up DOP 10 and 11.
Pascal

1 Like

it again the same problem:

Exporting an image in Photolab 2 yields different results than in Photolab 1. No access to the old process in Photolab 2.

And although the .dop file only got minimal changes by viewing the image in Photolab 2, it can’t be used in Photolab 1 afterwards.

Oliver

1 Like