Looks like PL 9 still can't read DNGs modified by other apps

I made a mistake by exporting a DNG to ON1, swapped out the sky for one with puffy clouds, then sent it back to DxO as a DNG and it was refused. This has been an issue since at least V5 and 6 it seems. There is a long thread about this.

So what do we do? I wanted to do some further edits with PL9 after the sky swap but it’s locked out. Can I manipulate the metadata to trick it somehow? Can’t save it as an NEF, and if I save it as a JPEG, my editing options are limited. Funny, though, the metadata shows the camera as a Nikon D750 (correct) but there’s something else goofed up because PL9 says it doesn’t support the camera used. Methinks this is an ongoing issue that needs to be addressed?

Seems that the workflow should be: 1) Make all your changes before exporting to another app; 2) Export it back as a JPEG, never to be touched again; 3) Cross fingers and toes that someday this might be fixed.

I think the only answer for you is to use 16-bit TIFF instead when exporting to PhotoLab.

DxO has written articles about how they choose to handle DNG files and why. You can find them by searching for DNG at support.dxo.com.

Since I wasn’t familiar with TIFFs, I was hesitant to export it back to PL9 as a such. Going forward, I will.

The whole issue is based on the fact that I had originally imported all my recent vacation photos into Lightroom, which dutifully converted the NEFs to DNGs. Now that I’m no longer using LR, all new photos will be NEF. The problem remains, though, that a lot of my legacy photos (years worth) have all be ‘adjusted’ to DNG by LR.

If I do export to ON1 or Affinity in the future, I have to remember to send them back to PL9 as TIFFs.

Curious, though, if there’s any way to manipulate the metadata to make it work, or does the DNG have irreversible changes made to it?

<< addendum >>
I didn’t realize that PL9 only supported DNGs created by Lightroom. I thought (incorrectly) that DNG was an industry standard. Perhaps it is, but there’s more afoot here than meets the eye. The only thingI have to remember when exporting to ON1 is to send them back as 16bit TIFFs. That way, I’ll still have the original NEF.

Yes, provided profiles exist for your camera-lens combination, PhotoLab supports DNG files created by Lightroom.

Try it out, but avoid applying (some) lens corrections twice. You can then export the file as a TIFF, for example, for use with ON1 or for other purposes.

The DNG format is standard (it was an open format from the start, and has just been published as an ISO standard earlier this year). But it also allows for a somewhat wide combination of data types inside the DNG wrapper. RAW “color filter array” (CFA) data for monochrome sensors, sensors with Bayer or X-Trans or other color filter arrays, RGB or monochrome layers for masking or depth metadata (as used by the iPhone), linear RGB data in an output-referred color space or in the camera’s color space (“scene-referred”). Plus 4 compression algorithms (lossless JPEG, lossy JPEG, lossless JPEG XL, lossy JPEG XL).

What’s more, some of those options are only specified in more recent versions of the DNG specification, not in the older 1.0 spec.

As a result, every software that supports DNG will typically only support a subset of the allowed data types. Things like bitmap masks and depth masks and JPEG XL compression are more recent and may not be supported.

Some software, like PhotoLab, may choose to not support Linear display-referred RGB data because it’s a use case already handled by other formats (JPEG, TIFF, PSD…), so why waste engineer time also supporting it for DNG?

It looks like that’s what’s happening with ON1’s DNG exports: they export the modified image with its arbitrarily generated bitmap data (the sky replacement) as a DNG wrapper containing display-referred RGB data. The solution here would indeed be to export as TIFF instead. And/or to try to do most edits in PhotoLab, export as TIFF, then do the sky replacement as the finishing touch in ON1.

Uh… I haven’t investigated yet, but a photo popped up yesterday in the browser that said it wasn’t supported by Photolab, even though it’s an NEF from a Nikon D800, and AFAIK, all of my other NEFs from that camera still open and work fine with Photolab. I think there is some “bugginess” in how PL decides it can or can’t edit a file. Very, very strange.

Edit 1: Haha! Nope! DXO now refuses to open ALL of my NEFs from the d800. What the heck is with this buggy mess?

Edit 2: Jokes on me. Indeed the NEFs in question were actually corrupted. They actually aren’t NEFs at all… No idea how that could have happened.

Thanks for the detailed response. Yeah, I’m using 16-bit TIFFs now for export. Initially I thought it would be nice to just overwrite the original DNG (stupid, in retrospect) with the ON1-modified DNG. Blame Lightroom for automatically converting the NEFs to DNGbats.

I have an open ticket with support for odd behavior in PL9.10. Perhaps the latest update is buggy.