Another post in Pixels inspired me to open up Lightroom and confirm that I can export a non-raw file as a DNG file. Now I am not sure if this really is an advantage because the original was a non-raw. However, I was wondering why DT doesn’t offer DNG as an export option and if it did would there be any advantages in doing so? Just curious at this stage.
maybe because no one had a convincing explanation that this could be useful.
even implementing foss software costs effort no one will spend if there’s no benefit seen …
1 Like
Thanks Martin. Hence my question as I wasn’t sure if it would be useful except maybe if you wanted to do your raw editing across multiple programs. For instance letting LR do a panorama stitch or HDR merge and then exporting as a DNG to edit the output in DT would be one of my current uses.
I stand to be corrected on this, but I believe that from a technical perspective, DNG has no advantage over a floating point TIFF - or even a normal 16bit tiff as long as there’s no clipping happening.
I suppose the advantage of DNG is compatibilty in some aspects.
But not sure TBH!
Non-raw DNGs are often high bit depth TIFF, and DT can already export all sorts of TIFFs. I don’t see what advantage DNG would have. If there is some advantage, please tell us!
3 Likes
I don’t see an advantage but I am wondering if anyone else can.
The real value of DNG is as a raw format. The content of its metadata is targeted at raw processing.
The limited benefit of non-raw DNG, coupled with the non-trivial development required to incorporate (the only DNG library of which I’m aware is the non-FOSS SDK available from Adobe; all the other image formats of which I’m aware have a open-source library reference implementation) make it a hard sell to resource-strapped projects.
Edit: libraw reads DNGs, but it requires the Adobe SDK to do anything significant with metadata decoding. Don’t know about rawspeed… at any rate, both are importers, not exporters.
1 Like
This is the right answer AFAIK.
I think the initial question is wrong.
Why should the devs have to explain (regularly) why a certain feature from program … is not implemented? For me, it’s up to those who want a feature to explain why it would be a useful addition to darktable’s possibilities (or, of course, code it, but that’s a few orders more complex).
3 Likes
With respect I feel the question was a fair question to ask in a DT forum. I wasn’t pushing for a feature request. I was seeking knowledge and asking if there would be any advantage because I personally couldn’t see one myself. But still I wondered if I was missing something since LR would export a DNG regardless of the input file. I have learnt a lot from the replies here. The developers never had to waste their time answering my question if they didn’t want to.
3 Likes
there’s one foss dng converter: GitHub - dnglab/dnglab: Camera RAW to DNG file format converter
1 Like
LR features are Adobes decision, darktable doesn’t care of Adobes decisions …
2 Likes
Based on the answers here there would be no advantage in dng export from DT. That is the knowledge I was seeking. I wasn’t requesting a new feature. Thanks for all your thoughtful replies. I did not mean to imply that DT was deficient in not having DNG export options. My question was possibly badly worded and misinterpreted. For that I apologise.
3 Likes
Yeah. There might be some very odd niche use cases for DNG as opposed to “TIFF with color profile”, but for the most part, the only scenarios I can think of where DNG would be desired over high-bit-depth TIFF+ICC:
Preserving the camera’s black point offset for further processing - unlikely to be something you’d be doing with darktable export
Preserving the camera’s white point for further processing - again, unlikely to be something you’d be doing with darktable export
These are probably theoretically possible with TIF+ICC even, but it’s a pain in the ***.
There might be some other niche use cases, but I can’t really think of them.
libtiff (or any other solution for TIFF writing) + exiv2 provides all you need. Actually the DNG tags themselves don’t even need exiv2 - pyimageconvert/libraw2dng.py at master · Entropy512/pyimageconvert · GitHub - but this really only makes sense for certain “low level preprocessing” setups like HDRMerge or my stacking script in that repo where you avoid doing any color processing at all and want to preserve the ability to use DCP profiles at the point where you DO perform color processing, or that image converter which will mostly stop being relevant once RawTherapee transitions to libraw. (It’s currently designed to ingest things that RT doesn’t support but libraw does into RTT)
2 Likes
Ah, so that’s where rawler comes from.
Yeah, in rawproc i went to using exiv2 for all metadata export, jpeg, tiff, and png. It’s even done as a separate post-export step, gets metadata out of image export entirely.
What I’m wrestling with now is that exiv2 doesn’t read Nikon lens distortion/vignetting tags. So I wrote a Rube Goldberg ‘run exiftool in a separate process’ thing to collect just those tags, something I’d like to get rid of in the near future.
DNG lens corrections are even more vexing; exiftool only delivers the OpcodeList tags as binary blobs. I wrote a C++ program that I can pipe those into to decode them so I could do my metadata analysis, but i’m not going to shoehorn that into rawproc…
2 Likes
dnglab:
- doesn’t expose a library for use by other programs to export DNG
- coded in Rust - cripes, another language to learn, getting too old for that…
2 Likes