Better HDR merge with auto-allignment

[gluckgluckwasserbauch]

Is your feature request related to a problem? Please describe.

I like to shoot HDR images. For that, I use exposure bracketing and shoot 3 images at once.
One underexposed, one optimally, and one overexposed.
Then I stack them onto each other to create an HDR image.

I didn't use Adobe Lightroom yet, but from what I've heard, it does that way better than Darktable.
The main reason: it auto-alligns the images to fit perfectly onto each other.
With DT, if I don't shoot with a tripod, they don't get stacked onto each other, which causes a very janky picture, even with super fast shutter speeds and a steady hand (see below).

There are a few LUA scripts that do that, but I couldn't get them to work.
(And, tbh, having to resort to janky scripts for a basic feature like that shouldn't be standard imo).

Also, the colors are quite a bit off and the whole image looks very artificial, even if it would be stacked correctly.

Describe the solution you'd like

My idea would be to add a dialog window after clicking the "create HDR picture" button.
In the dialog, you can generate a preview and have some toggles, like 'Auto-allign if possible', 'Set transparency' for every frame, and maybe some more.
It should also be possible to safe those preferences and apply them automatically.

This feature could be relatively easy to implement. It is basically just a GUI-frontend for some already existing scripts, like Hugin, ImageMagick, Enfuse, and maybe some more.

Alternatives

• I tried a few scripts before, but Hugin (and a few others) failed, and those that worked, didn't create a usable picture.
• There's also Luminance HDR, but that threw off the colors the one time I tried it.
• I used Conversion Tool for the sample photo, but even that didn't look great.

Additional context

How it should look like: (kind of)

How it actually looks like in DT:

[wpferguson]

(And, tbh, having to resort to janky scripts for a basic feature like that shouldn't be standard imo).

darktable is a raw processor, not an HDR tool HDRmerge, enfuse, etc. are HDR tools. Lua scripting is built into darktable to allow extended functionality for things that darktable doesn't, can't, wont, provide natively.

There are a few LUA scripts that do that, but I couldn't get them to work.

Did you try raising an issue or asking on forums?

[jenshannoschwalm]

@wpferguson we might want to discuss "remove the dt HDR merge code" as of too-low quality?

[wpferguson]

IIRC I tried the HDR in darktable 3 cameras ago (~8 years). I created the HDR from 3 images, but then you had to apply the global tonemap module to get something usable. I never had much luck using it. Houz had written the official/enfuse.lua script by then and I used that and got good results.

Since global tonemap is deprecated I'm not sure there is a way to get a usable HDR from the darktable HDR merge.

[wpferguson]

The left is darktable HDR with scene referred defaults. The middle is HDRmerge. The right is enfuse. I didn't edit any of them, so this is just the output of the process

EDIT: The raws where -1.3 ev, 0ev, and +1.3ev

[wpferguson]

This is enfuseAdvanced output

Pretty close to enfuse exposure wise, but with image alignment.

[wpferguson]

HDRmerge and enfuseAdvanced align the images. enfuse doesn't, but it could be added to the script with a couple of lines of code. darktable does not align the images.

[wpferguson]

HDRMerge can take raw files, so no export required and produces a DNG file. So essentially it is the same as darktable HDR but with image auto align.

So this means that we could "replace" the Create HDR button with another Create HDR button other than the button would be the full width of the module instead of half width and run a script that runs HDRMerge.

[wpferguson]

I'll play...

[wpferguson]

I played 😄

Here's a handheld HDR bracket merged with the current darktable Create HDR

And here's the same bracket with HDRMerge triggered from a script

You can see the misalignment in his head and especially in the fence, which is fixed with HDRMerge.

The script works, but it needs a couple of changes to provide more feedback to the user.

So what do we need to do to make this a replacement for the current Create HDR?

We need HDRMerge

Do we....

• Tell the user that darktable now uses HDRMerge to create HDRs and it's the user's responsibility to install it? Packages are available for Linux, Windows, and MacOS so it shouldn't be a problem, but it is a step.
• Include HDRMerge as a binary in the darktable bin dir?
• Add it as a subproject and build it along with darktable?

The lua-scripts need to be part of the darktable package

• If we are going to rely on the scripts to provide "core" functionality then they should be distributed as part of the darktable package instead of relying on the user to install them. In 4.7 @TurboGit added the lua-scripts as a subproject so that we could work on using darktable's translation facilities for the scripts. We didn't finish it in time so we pulled it back. We're ready to start on it again. Yesterday I played with packaging the scripts as part of darktable and got it working. It's still a work in progress, but it can be done.
• Scripts that provide "core" functionality should be put in a "system" directory and started automatically, i.e. they should "just work". I'm also working on a script that persists grouping across database instances and it would be a candidate for this.

EDIT:

We also have to think about package formats, i.e. appimage, flatpak, snap, ??? Packaging the scripts and HDRMerge would solve this.

[JLTastet]

I would like to second @gluckgluckwasserbauch’s enhancement request.

I also use HDR merge a lot, but with a slightly different goal: I have started editing some of my photos for high dynamic range displays (think Rec. 2100), exporting them to HDR formats like JPEG XL, AVIF, UltraHDR JPEG, etc.

For HDR edits, it is critical to preserve the highlights, while still having decently clean shadows. But, sometimes, even the dynamic range of a modern full-frame camera isn’t sufficient for this, and I will use the burst mode to perform some basic handheld bracketing (often just an extra -3EV exposure) to recover some dynamic range. This pixls.us post contains an image produced this way.

Having the HDR merge feature directly accessible in Darktable is very convenient, since it produces in one click a DNG file that can be edited just like any other raw file, but with increased dynamic range.

However, while I sometimes obtain good results if my hands remain steady and the IBIS does a good job (or I brought my tripod), most of the time the shots will be shifted/rotated by a few pixels, leading to a low "keepers" rate.

I can usually recover the shots by aligning them with Hugin while preserving the full dynamic range. To do so, I use EXR as input and output format, and I disable any exposure blending/compensation and tone mapping. This also requires applying all corrective modules before merging, and manually managing the colour spaces (I do everything in linear Rec. 2020), since EXR doesn’t store this data. So, while certainly doable, the process is quite cumbersome. I have also tried the Lua script, but this didn’t work at all for me, producing completely wrong colours.

All that to say that having a working HDR merge button with auto-alignment within Darktable could be very useful, regardless of whether it is implemented in Darktable itself or outsourced to a Lua plugin (just not the current one, which seems broken). For me, the most important part is to have the option to disable any tone mapping and get a scene-referred, (perceptually) lossless, "raw-like" output, like a demosaiced DNG or another high-bit-depth file.

Just my two cents.

EDIT: I now remember the issue with HDRmerge. The stable release is massively outdated (2015) and produces incorrect colors, while newer development versions are only available for Linux (but not Windows or macOS). So using it instead of the current "Create HDR" would amount to dropping support for this feature on two platforms.

[github-actions]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.