@DavidOliver At least one of the formats spit out by hdrmerge (16, 24 or 32 bit floating point) is not supported by dt. I don’t know which one it is. But if you try all of them you should get a dng which can be imported by dt.
Ingo
Thanks, @heckflosse. Unfortunately, I’ve now tried all three bit-depths and the problem exists for all of them.
Then you have to ask in dt forum 
Ingo
Floating-point DNGs are unsupported by libraw and programs which use libraw.
I opened a request at libraw’s issue tracker for adding support for it in 2014, but the request was closed.
If you want support for it added to libraw (and thus enabling support of it to every program which relies on libraw), click the link above and voice your support.
Ah, I see - thanks. I should have caught on as it’s covered in HDRMerge’s readme. So my workaround would be to save as a 16-bit integer TIFF using RawTherapee, either before or after tonemapping, for use in Darktable.
I’ll add a “me too” to that libraw issue, but it doesn’t sound like it’s something that’s going to be done anytime soon. I see there’s also a request to add an option to HDRMerge for integer output.
I was excited that someone requested integer output… Until I realized that it was me.
1 Like
darktable doesn’t use libraw, so fixing that wouldn’t change anything. Last I checked the problem with HDRMerge DNGs was that they are zip compressed which rawspeed doesn’t support. See if you can turn that off.
Currently HDRMerge is hard coded to write compressed DNGs
@patdavid How about adding a new HDRMerge category in ‘Software’?
Morgan_Hardwood currently tries to crosscompile a new HDRMerge Windows build on Linux (any help is appreciated) and there are also thoughts how to continue (improve) HDRMerge project. Currently the only active contributors are Morgan and me. We welcome new contributors. The code base of HDRMerge is small and clear and if there are questions about the code I’ll give my best to help.
Ingo
2 Likes
Will do! I’ll get it set up tonight after I get the kiddos to bed.
1 Like
I also think this is probably worry a blog post at least to raise some awareness. I’ll start on something later this week and try to get it mentioned in some other places as well.
2 Likes
Thanks, Pat! I’ve a lot of ideas how to improve HDRMerge like using a different decode engine than libraw; raw preprocessing as in RT (badpixels interpolation and raw ca-correction before merge and so on…)
1 Like
I think that some automatic distortion correction (maybe with lensfun) could help with the alignment of handheld shots.
Also, is there a CLI version without QT dipendencies?
I could help with an appimage, of course 
Since darktable has a built-in facility for creating an HDR DNG from multiple RAWs, is there a need for this?
Does DT also support automatic alignment of handheld shots?
Anyhow, the need is there for all those who do not use DT… 
The need to import into DT is not needed for those who do not use DT. Which
was the subject in hand.
However, I do not believe DT supports automatic alignment, so I guess there
is a need.
Note that Darktable can’t process the DNGs from HDRmerge since it uses floating point data.
1 Like
I don’t think that’s possible, it’s raw in raw out.
darktable cannot read raw files from HDRMerge not because they are floating-point but because they are deflate-compressed and tiled (that’s not a bad thing, quite the opposite, it just needs to be supported).
1 Like
iirc the only correction which lensfun applies to raw data is ca-correction