Help! I can’t export my Light changes to non-compressed DNG! It worked in the previous version! I know the limitation with the new High-Fidelity compression what can be exported. But even No Compression does not keep my Exposure correction, etc!!! (Verified on two different Macs) How can I get the previous dmg-file (v.9.6). I did not keep the last one… Could not even imagine that this would break like this.
The change in PL9.7 doesn’t just affect the new compressed DNG output. All new DNG exports have this limitation. This has surprised some people, as the behavior is mentioned in the software release notes (support.dxo.com) but not in the software itself. From the release notes:
Known Limitations: • The previous DNG export option has been removed. Existing DNG files created with prior versions of DxO PhotoLab remain fully compatible.
Someone will have to send you PhotoLab 9.6, unless you backed up the previous version. (It’s a good habit to keep backups!) Or change your workflow since DxO is intent on having linear DNG files be an intermediate part of one’s workflow.
1 Like
Sigh… This is, as you say, affecting both DNG options…
“If you need to apply creative adjustments (color, tone, exposure, etc.) in DxO PhotoLab and continue editing in another software, we recommend exporting as 16-bit TIFF.”
My clients need DNGs with these corrections done… They were happy what I delivered until version 9.6 came out.
That killed the most important thing for me. Burned my investment of DXO Photolab 8 & 9.
How can a developer just remove features that professional photographers rely on and why they bought PhotoLab 9 for that specific reason?
2 Likes
I totally agree. It’s unacceptable of DxO to do this. It’s the editing software equivalent of if apple made their camera app only able to shoot in 10 bit HEIC - it’s just not going to work. Not all software is compatible, and DNG though still somewhat dated, is miles better than TIFF, and for many workflows this change only increases the file sizes, not decrease. I’m so tired of DxO being stingy with what files you can and can’t edit. It’s unacceptable that editing software that costs this much money, will neither export as a DNG with all edits, nor edit any arbitrary DNG. We paid for the software, you’re not paying for the software, so let us use it how we want, please! This whole situation has made me feel stupid for having invested $500 CAD in DxO software. You’re telling me I paid that much, and I still have to use RawTherapee or GIMP to modify files from cameras that aren’t supported? DNG is an open format. I should be able to export and import from it exactly as I see fit, being that I am the owner of the software, having bought a license from DxO.
1 Like
I did reach out to DxO support. If you can call that support… Got an answer back with no help or real explanation why they ditched the previous way to export DNGs. They could not even send me version 9.5, that actually worked for me. I need to stay on 9.5 and use it until MacOS kills it in the future.
Just need to find 9.5…
The really sad part is that I can’t continue to support DxO with my money buying upgrades when version 10 comes out as I can’t use the DNG export as it was. I do NOT want to go back to Adobe. That is a dead end. What is the options then?
Support can now switch to an AI answering machine. It’s a shame.
AGREE, AGREE. Only solution: Ask DXO support to provide link for installing version 9.5 with the “normal” DNG export options. However, the arrogance of DXO is sickening. They communicate now as if exporting DNG with all corrections applied had never made any sense in the first place. So why then was this option available in Photolab for many years? This arrogance most likely simply is due to the unwillingness to disclose the real (commercial) reasons for removing this feature, whichever these reasons might be. Honi soit qui mal y pense.
1 Like
DxO has a history of changing things without regard to backwards compatibility. Two other recent examples are removing PRIME from PL9 and changing the documentation to state that dop files are not compatible between Mac and Windows (instead of fixing the existing problems). These kinds of things are the reason I recently gave up on PhotoLab.
1 Like
Seriously? That’s insane given I’m planning to switch to mac. DxO might wanna rethink their strategy then because if I can’t use my old edits, I’ve no reason to keep using Photolab other than I already have a license.
1 Like
Was it after 9.5 Build 40 that it changed ?
I might have a copy on Time Machine
I have the application not the .dmg file
Here, with similar warnings in the User Guide.
Dop has been previously documented as compatible across platforms (you should still see that in earlier versions of the User Guide), but PL hasn’t quite lived up to it. The biggest problem for me has been that absolute paths to profiles (eg. DCP, LUT) are written to dop: opening an image with a dop that references a path written on the “other” platform either results in it being silently discarded or an error; either way it has to be fixed manually.
Not an impossible problem for DxO to solve, but they’ve seemingly decided they’d rather not bother and are happy with there not being a reliable way to move edits between hosts. Paths can be different even across hosts on the same platform, so writing paths is not really just an issue between Mac and Win, it can be an issue between hosts on the same platform as well.
Others have run into issues with local corrections, if I recall correctly.
1 Like
Found a backup myself eventually! And I could even still download version 8 from an oooold download mail, (when that expected service still was available) so I can fall back to that if needed. 
Bye DxO!
You can also log in to your shop account and re-download all versions you have bought a license for. The latest dot releases that is, earlier dot releases can mostly be found in backups.
Sadly no. DxO PhotoLab 8 is not listed in my user account for download. Only v9 shows. But I can see in the License Manager that I have a license for DxO PhotoLab 8 as well still showing.
Strange, but I am not surprised anymore.
So luckily I found that email like a needle in a haystack to be able to download v8…and fortunately the v9.5 version from one of my forgotten backup drives.
1 Like
When macOS downloads the dmg file, it often also records the url of the file. Copy that url and keep it as a bookmark for future downloads. When edited, the url also gets other versions which might serve…if one has the license to use it.
1 Like
But the URL is not unique for each release. Looks like this: https://download-center.ocd.com/PhotosLab/v9/Mac/DxO_PhotoLab9.dmg
As written above, the link gives you the most recent dot release, e.g. 9.X, 8.Y, 7.Z with whatever the latest figures for X, Y and Z are.
Downloading the installer does not bring back e.g. 7.Z-3, but the latest available version. You can get earlier-than-latest releases in your backup. No backup, no do. But from here on, you can download the installer after each update and keep it safe for fallback, in case you need it. It’s certainly good practice for the current major versions (e.g. PL9), but it takes some drive space.
One other way to work around new-PL-release-issues on MAC is, to duplicate the app and leave it be while you update the original copy for testing.
Version numbers: Use whatever suits your needs. Some of the numbers shown above correspond to the then available version and build numbers, others don’t.
For Windows, things seem to be more complicated, but a decent backup strategy might help nevertheless.
1 Like
That method is just so sad to see exists to be forced to collect versions locally and is not common, even rare, that a developer does not allow users to download previous versions alternatively remove a dependent feature in a middle of a version.
I did not know that DxO developed some users to become hoarders like this.. 
Instead DxO sanely should have called 9.6 = PhotoLab 10 (free for existing users) and kept everything as it was in v9.5 and downloadable. That would be the way to secure the situation for users that have become dependent of a certain core workflow..
As v8 still CAN be downloaded via an old email and used, they do not again stay consistent where the old way of DNG is still alive and kicking and can be used.
So strange that the user account does not have v8 downloadable but License Manager shows it. Of course v8 should then be available.
1 Like
Well, the thing is, that the license is perpetual, but if PL9 was licensed as an upgrade to PL8, PL8 is removed from the list…which seems to be inconsistent with the concept of perpetuity.
As for hoarding: true, but I’ve learned my lesson and time machine will simply add the installers piece by piece, and when I use some form of version numbering, I’ll be able to reinstall whatever version I have.
I’ve used the word “backup” a lot lately… Do you have any backups?
From a purely technical standpoint, that’s not a good expectation because DNG is not designed for edited RGB data, even in its Linear DNG form. Using 16 bit TIFFs would be better. But of course if your clients require a specific format, pedantically telling them “hmm that’s not the ideal format for this” might not help.
This situation with the changes of the DNG exports in PhotoLab 9.6 is such a mixed bag:
- Technically, DxO is right that trying to save light and color edits as a linear DNG in the camera sensor’s color space is a somewhat bad idea. It’s a recipe for issues and bad edge cases. This can mean that DxO has to spend too much time chasing bugs linked to that feature, or has to spend too much time making sure they’re not breaking that feature when working on new features. That’s called technical debt, and it can slowly kill a product when it accumulates.
- But in practice, they shipped that feature for a long time, a bunch of users were relying on it and not running into issues and bad edge cases for their own use cases. Removing the feature suddenly is user-hostile.
The correct solution, if DxO didn’t want to keep paying interest on this bit of technical debt, would be something like:
- Only remove the feature in the next major version. It’s common practice in software development (look up “semver”), and lets users choose whether to upgrade or not if they want to retain the feature.
- Warn users that you’re going to remove a feature. You can also have a staged deprecation process, where you visibly mark a feature as deprecated in one major version, and remove it in the next major version. (That means paying off the tech debt for a longer time though.)
- Offer good alternatives. If 16-bit TIFF is a better format for RGB images with baked-in light and color corrections, can you tweak your export presets to highlight that format? Can you add support for TIFF compression (LZW, DEFLATE, or both)? Can you offer other good formats for 16-bit RGB data, such as JPEG XL (lossless and lossy)?
My pet theory is that DxO wanted to add the compressed DNG feature to PhotoLab 9.6 in lockstep with PureRaw 6 for marketing reasons, but the PhotoLab team could not make the deadline if that meant also supporting DNG-export-with-edits for the new format, so they chose to cut the conflicting feature to make the deadline. Which, in hindsight, was not a good way to handle this issue.
5 Likes
DxO indirectly admitted they’ve made a mistake allowing to store non-linear edits as LinearRAW data:
https://support.dxo.com/hc/en-us/articles/34450035269277-Why-does-DxO-PhotoLab-now-export-DNG-files-with-only-technical-corrections .
While technically possible, the results can be far from intended.
To do it correctly, one would have to store LinearRAW data (demosaicked RAW but still in camera linear color space) separately from non-linear edits, which could be provided using DNG masks and embedded DCP and XMP instructions for Lightroom or Photoshop. This would make the output fully compatible only with Adobe products. After all, one of the reasons of developing DNG format was to bind you with Adobe. In theory DxO could embed DOP file inside DNG, say as a MakerNote, but that would make it fully compatible with DxO only.
BTW, does anyone know how Lightroom does it? Any full exiftool output?
Generic LZW and DEFLATE are byte-oriented and ignorant of RGB channels sequencing. Some RGB TIFFs can get even larger after LZW compression, also for 8-bit encodings. One could use suitable DEFLATE modifications, assuming 16-bit input and compressing the color channels independently, but there’s no agreed standard for the resulting format, afaik. Also it wouldn’t be too good, as DEFLATE doesn’t take image data specifics into account, e.g. usually small “deltas” per channel. Using JPEG XL compression in “standard” RGB TIFFs would be a good solution, but I’m not sure what’s the industry stand on that. Once again, compatibility nightmare…
1 Like