I’m using a ‘sturdy’- ish tripod as the manual suggests, but of course this doesn’t address the issue of things moving in the image - like tree branches for example. dt doesn’t provide for any form of ghost elimination, so what is the generally accepted method for creating un-ghosted HDR images? HDRMerge and Luminance HDR seem to be work in progress in this regard.
I use HDRmerge. Not sure what you mean that its a “work in progress.”
i use the “merge into current” button in lighttable view in vkdt. it appears under “selected images” if you selected more than one image. it’ll merge multiple raw files as inputs to a node graph via the align module. it has the caveat that it can’t currently align images of different exposures. it will create “hdr” by lowering the noise floor and thus increasing the dynamic range of the output.
i suppose an extension to bracketed shots would be a bit of work but straight forward to do.
porting it to darktable would be painful (the pipeline does not support multiple inputs, so it’d be special cased side channel code) and slow, but possible.
1 Like
Thanks for this - that’s easy for you to say! Having looked at vkdt on Git I conclude that it’s all a parsec or three beyond my pay grade. I’ll have to stick with hugin or, sadly, maintain a Windows install so that I can use Photomatix.
Perhaps I might be better off improving my choice of lighting and composition so that my images can be more readily handled in filmic and tone equalizer …
Not having the skills to make relevant, accurate or useful comments on HDRMerge, I used this expression, which I hoped would not be derogatory. I tried HDRMergse last year, personally finding that I could get no useful output. Based on your comment I have spent the day so far trying it again;
- The Windows and Linux version cannot process raw files from my camera.
- the 64 bit Windows stable version will process dngs created from my raw files, but the merged output has no useful value - it is a predominantly a chaotic collection of red artefacts, some of which can be related to the original images
- the Linux Appimage development version 0.6 closes immediately after loading the input images, so it produces no output, useful or not.
These results are the same as those I observed early in 2021, so I conclude that, with my current knowledge level, HDRMerge is not for me.
Sounds like there may be issues that could be addressed. If you have the time check Issues · jcelaya/hdrmerge · GitHub to see if we need to investigate/report them.
1 Like
Yup. The camera in question hasn’t been specified, but it sounds like a “camera not yet supported” issue to me.
HDRMerge works great for me with multiple Sony cameras.
The one observation I will make regarding artifacts: In some cases of a scene with significant dynamic range (In my case, a Christmas tree taken with 3EV bracketing steps), HDRMerge defaults to float16 but you really need float32 output, easy enough to change that in the settings.
This confirms what I assumed - available versions of HDRMerge cannot handle RAFs produced by my camera. DNG Converter converts RAFs without problem. I have run DNG converter at every level of CameraRaw: for older versions (CR version 7 and earlier) the preview produced by HRMerge is obviously a merged image of the raw inputs, but the colour is a uniform dark green, while the saved HDR is, as previously stated, a chaotic mass of red coloured artifacts.
Other reported problems may also be applicable but I am not able to tell. On balance, bearing in mind that the developers of HDRMerge are (quite understandably) not in a position to respond quickly to requests, I’ll continue to use alternative approaches through Photomatix or Hugin.
Since its dev stopped, RT devs have been contributing to it, though at a rare maintenance rate.