I have taken a bracketed exposure shot in raw mode with fixed camera position and am trying to merge them in DarkTable. I am relatively new to DT and raw photography, OTOH I got a lot of technical background knowledge (physics, vision, digital image processing). My goal was to bring out the perceived “glow” of the mountains in my picture, taking during dawn, but even after quite some processing, my results looks even more dull than the built-in camera JPEG. (I guess this happens to many RAW newbies, and I take it as a sign that my camera is in general doing “the right thing” already.)
One thing I wondered about is that opening the “DNG HDR” created by DarkTable (4.0) itself results in the message “unsupported input profile has been replaced by linear Rec709 RGB”. Is this expected behavior? My input DNGs have an embedded matrix that results in a different appearance than any of the standard input profile setttings.
Furthermore, is my assumption correct that combining multiple (DNG) RAWs in the lighttable view does not depend on their history? Having just read Aurelien Pierre’s Hugin HDR workflow post from 2021, I wonder if DT just takes the raw data (someone even wrote the HDR composition takes the raw sensor sub-pixel data before demosaicing) and if the result really is linear Rec709 RGB. If I would do the HDR composite in Hugin, I could obviously choose the output profile (HDR stitching workflow profile) myself, but I assume I can’t with the built-in HDR feature?
Great, so you can start w/ some troubleshooting yourself
E.g. by inspecting the output of exiftool -a -u -s -g1 on both the original DNG files and the HDR one produced by dt. The tags are explained in the DNG spec, and you want to focus on the color profile related ones obviously.
However, I don’t know if this is intended, since I am not 100% sure what the HDR composition actually does. So far, I have found my results to be superior if I just picked the “best” exposure from a bracketed shot and worked from there (often, the one preventing overblown highlights most), but I wonder if I am missing anything.
a) convert your OOC DNGs w/ Adobe DNG Converter and try dt on those again to confirm this is indeed the case, and
b) file a bug report on rawspeed so we don’t loose this @cytrinox (also need to handle the case when D65 calibration is first, and not assume Adobe DNG Converter output order as well)
Just for reference to clarify the “Adobe DNG Converter output order”. The DNG spec says:
If two calibrations are included, then it is recommended that one of the calibrations be for a
low color temperature illuminant (e.g., Standard-A) and the second calibration illuminant be
for a higher color temperature illuminant (e.g., D55 or D65).
This is true for many DNGs from Adobe Converter, but not for all. For example, some Phase One IIQ files are converted with another set of calibrations. The IQ3 100MP Trichromatic DNGs uses Flash + Tungsten, IQ150 uses A + Flash and iXU180 only D65. The Canon 1D uses only D65, too.
I must admit that your explanation of the bug above was much more clear to me than how it is addressed by the PR. (Then again, I am already sweating when I read isnan()… I learned to avoid NaN whenever possible.) I will try to build DT, but it will obviously take a while.
Furthermore, should/could there be a unit test? My camera (Ricoh GR III) has sample DNGs in the database, so from my (outsider’s) perspective, it could make sense to implement a test that prevents similar issues for any other camera as well.
FYI there is room for improvement for dt’s internal “create HDR” function. If you’re planning on doing a lot of exposure bracketing, it would be worth it to set up the lua script for HDR Merge or Luminance HDR.