DXO or LR pano/HDR DNG files contain the Demosaiced 16 bit image file (16 bit Tif) without a white point being set. Some people believe that if the file extension is “DNG” that they are maintaining a full raw workflow. Adobe are quite happy with this incorrect assumption.
Raw converters treat them as Raw files (Mosaiced) and therefore apply their own default Raw Converter settings which will include colour and tone curve adjustments as well as White balance. Therefore they can look different to how they look in the original raw converter. This is why the same raw file looks different in the different raw converters as they each “interpret” the raw data into a RGB image differently.
If you want to retain the same RGB values in the output file when importing into an alternative editor use Tif.
I doubt that. I exported a file of 6048x4024 pixels. In 8 bit that would be 73011456byte or 73MB.
In 16 bit the double or 146MB.
On disk it is 77MB.
My conclusion is that PL exports the DNG as 8 bit.
Thanks for the information. As mentioned, I’ve never seen this scale of shift in the DNG files between PL > PS > Neo before - it’s always been minimal, so never really an issue.
I prefer the resulting corrected DNG files from PL and have exported a few as TIFF to experiment with. As you say, they keep all of the corrections when opened elsewhere so I’ll keep experimenting and see if there are any downsides to this workflow compared to using the DNGs.
The DNG exported from PL is a 16-bit file, same as a linear export from Adobe’s DNG Converter. You can confirm this yourself in a pixel editor such as Affinity or Photoshop.
The Linear DNG files are nearly half the size of the corresponding TIFs when exporting Sony A1 images at 8640x5760 pixels. The TIFs are 298 MB in size.
Linear DNG filers from Adobe’s Camera Raw or DNG Converter are 158MB or slightly higher depending on a few settings.
Linear DNGs from DxO’s Photolab are 177.3 MB or a bit higher if some adjustments are applied.
Adobe’s DNGs are also slightly smaller than Sony lossless compressed RAW image from my camera. (49 MB vs 58 MP generally).
When exporting from DxO Photolab be sure to confirm no corrections are applied and choose the export option “DNG (Denoise and Optical Corrections Only)”. When using the “DNG (all corrections applied)” option there appears to be some lifting of shadows and colors that get re-applied when round-tripping back to Photolab.
The DNG files from both DxO PL and Adobe products show “sRGB IEC61966-2.1” as a color profile in the metadata section. Not sure, but think this only applies to the embedded previews.
Note that PhotometricInterpretation is set to LinearRaw (34892), so Compression=7(JPEG) means that only lossless Huffman is used (the last step of jpeg compression, so no DCT tables are applied). See DNG Specs 1.7.1, paragraph on Compression starting on page 20.
DNG produced by PL from RAW contains also full resolution standard JPEG (as a preview).
Do you mean PhotoLab-created DNGs fit that definition? Technically “some random DNG” could just contain JPEG data and nothing else.
You’re not alone. It is both a singular concept and also an infinitely flexible tool. Some of us have cameras that can natively record in DNG format.
The conclusion I have come to for now is that this is neither a good nor a bad thing. The native PEF (Pentax) and the native DNG are within a whisker of the same size and you can (generally) only read either one with the right software (certainly in the case of DxO, it needs the body support either way).
I chose DNG a long time ago. If I were to make the decision anew today, I’d probably just stick with PEF. But I couldn’t really tell you why and, given I have thousands of DNGs in my catalogue, I don’t see the point in changing now.
Compression is normal. Even TIFFs will generally have compression. But lossless compression. This was one of the areas of TIFFs that used to cause incompatibility problems, where some software would only support, or assume, one of LZW or ZIP compression.
Actually, one definite advantage of DNG files, at least in the context of camera-native ones, is that a lot of software, PhotoLab included, will write meta data into the file itself, removing the need for XMP files.
Some say the “risk” of corrupting your original is present in this case, but I say the risk of the native RAW and XMP becoming “divorced” is actually a higher one. I’ve got over 40,000 DNG files, often go back and update keyword hierarchies (in LrC) and have never yet had a corrupted DNG.
The corruption risk is whether you trust your software. The file divorce risk is whether you trust your software and yourself.
That was the case with the NEF from Nikon too. CaptureNx and ViewNx wrote metadata and even the edits to the raw file. Even different edits. I still use the old ViewNx to write metadata to the raw file though I can’t edit the file, my camera’s are not supported. XMP and IPTC was also meant to write directly to the main file.
Just don’t forget that for the majority of RAW files, the image data is held in a separate block from the metadata so, if you use reliable software, the risk is infinitesimally small.
I have been writing metadata directly to NEF (and other) RAW files for many years, using ExifTool, via my home-brewed app. There is an ExifTool command that takes a copy of the original and at the same time, it renames the original with the .ORG extension. Then it makes edits to the copy and verifies those edits and the integrity of the file. Once verified, it can optionally delete the .ORG version. Otherwise, it deletes the .ORG file. If, for some very rare reason, the edited version gets corrupted in editing, you still have the .ORG file that you can simply rename.
I can say that, in all the many years I have been doing this for many thousands of images, I have never had as much of a sniff of corruption.
The bonus of writing directly, at least on a Mac, is that you can use macOS Finder’s excellent Spotlight search to find your files by metadata without the need for a third party app.
Never heard of.
ALWAYS work on RAW copies with software that may open them in RW mode.
Even if your app is 100% bug free, any asynchronous kernel routine (e.g. servicing timer interrupt) can crash the OS, possibly resulting in data corruption, even with single-threaded MS-DOS in the old days. Your app code never walks alone.
The file isn’t opened. Just some extensions added. The problem you mention can also happen with renaming or copying. I’m doing this since my first Nikon, 2008.
Thanks for the detail. As the file sizes from different images varied, images with lots of shadow tones were much smaller than well lit detailed scenes, I assumed they were lossless compressing files.
