Darktable says none of the 3 raw files have clipped sensor data. Could it be that Lr simply took the brightest of the 3 images (since it had the best signal:noise ratio, and no clipped pixels), and ignored the others?
HDR sequence-3.pef.xmp (26.4 KB)
I am using a Fuji camera and despite the fact that it includes an in-camera HDR option I find that bracketing for dynamic range is unnecessary.
We all have camera tools to avoid ‘clipping’ and assist us in correctly compressing our raw data.
@Mike_Bing @kofa I don’t want to go too far down the rabbit hole about Lightrooms HDR merge. I am on this site to learn about and promote FOSS. Sometimes I will make comparisons to paid programs as a comparison rather than a bench mark. Darktable exceeds most if not all paid programs for it ability to give artistic control to the person doing the editing. However, the OP asked about HDR in DT and this is one area that is not a strength of DT. I just point out that since I have access to Lightroom V6 that I find it very good at merging bracketed exposures that are hand held. LR then gives me a 32 bit file that I take to DT rather than continuing my editing in LR. And @kofa LR does not simply take the brightest image, but in fact creates a merged image. The sample image could have been handled with a single exposure, but this is a nice example of lightroom’s ghosting solution. When and if I no longer have access to Lightroom I would like a good FOSS solution. Hugin may be a good choice.
@ mike thanks for your detailed reply which I read last night before you deleted it. It was a well thought out reply and I found it helpful. The truth be told I do not understand if there is an advantage in getting a 32 bit floating point file from any program, let alone Lightroom. I can and have seen the problems of working with 8 bit JPG or Tiff files, but it seems to me these problems go away if you have a 16 bit file. 32 bit seems overkill to me, but maybe there is an advantage I am not aware of and learning is why I participate on this forum.
BTW, another form of merging we do is panorama stitching. When I teach darktable or imaging classes I teach using darktable in combination with Microsoft’s Image Composite Editor for Windows users, and Hugin for users of MAC or people who have Windows and would prefer to use Hugin. Hugin is a great solution and easy to use for panorama stitching. as a side point, in 21 years of teaching photography and imaging classes I have only ever had one single student turn up with Linux.
Have a good weekend everyone, and I hope @Daniel_Spenner has found the information he was looking for.
What I was saying is that for the particular set you presented there was no point in the multiple exposures from an HDR point of view, as there was no clipping in any of the images. Since, with a single image, there is no ghosting, there is no problem. And, if intending to merge exposures, I’m wondering why you took the images several seconds apart, and not in a burst (I’m sure the camera can make an exposure bracketed series).
However, I do not doubt that Lr can work better in certain scenarios, and has some features our FLOSS solutions currently cannot match.
Regarding the ‘do one thing’ approach:
digikam uses Hugin for exposure merging: Digikam/Exposure Blending - KDE UserBase Wiki
And Hugin may use a numer of tools for aligning shots, including align_image_stack. The philosophy is the same as with darktable scripts, only the integration is direct, rather than being provided by a script.
Thanks Kofa. I understand where you are coming from. As I say these images are more for testing a software’s capabilities. Hugin is a nice merging program and I do promote it to my students. I don’t promote Lightroom although I do recognize its strengths if people want to pay a subscription.
@Terry_Pinfold
I did in fact understand that implementing a more advanced merging performance in darktable is not considered worthwhile by the majority of the users in this thread. I will retry Hugin, which I am already using for panos and if it doesn’t work, then I’ll try digikam instead. The idea of one software for one task seems illusionary to me though. All the software mentioned above is doing far more than one task and I at least don’t like to have several tools installed for image processing.
However, thank you for your kind help.
You won’t be able to avoid installing multiple tools. As I mentioned above, Digikam uses Hugin, too. Hugin itself is made up of several components (OK, they are all installed when you install Hugin), implemented as command-line applications: Hugin - PanoTools.org Wiki
I regularly use align_image_stack to align images and enfuse (a tool external to, but used by Hugin) to merge them, without firing up Hugin (I have a script to quickly merge exposure series from my phone, where bracketing is often needed because of the low dynamic range of the device).
if you can’t spend the effort to do something better, use the existing stuff is quite common in foss development.
As long as no one bites the bullet and implements a new HDR algorithm himself because he needs it, it won’t be done.
There’re plenty of good ideas around that are frequently suggested but spare time deveopers invest their time on stuff they prioritize …
Just two (for me) small problems: it’s not open source, and for MS-Windows only.
A badly aligned result.
and
Terry, could you please share the Lr output? (Converted to a JPG, we don’t really need the DNG.)
I agree here - under the assumption that black level subtraction is performed BEFORE converting to float16. Black level is re-added to output, leading to inefficient use of representable dynamic range · Issue #216 · jcelaya/hdrmerge · GitHub
Does everyone here only bring up the topic of open source programs?
Lightroom, EasyHDR
SNS-HDR Lite is freeware.
Yes, this forum is specifically dedicated to free and open source software.
If the application is free/gratis, but we can’t have the source code, we are mostly uninterested.
I got a better result in HDR projects 5 obtained free of charge in the past
No doubt that some proprietary programs perform better, but that’s missing the point of this forum.
Hmm…even I am questioning what LR has done here and if LR has just picked one exposure to work with as @kofa suggested. BTW, the dark spots in the sky are a dirty image sensor and not artefacts. I am not sure these images are as fit for purpose of testing software as I had previously thought. Back to the drawing board for me, but I still have found the discussion illuminating and helpful. I certainly intend to test out Hugin’s ability with HDR more, but using more suitable images. Hugin is certainly a very capable panorama stitching program that I am happy to use and recommend.
That’s the same as @Terry’s Lr output, generated simply from the darkest image, HDR sequence-1.pef. Note the positions of the people.
I wonder why both Lr and ‘HDR projects 5’ took the darkest, noisiest image, when none was clipped.
As a matter of interest … I wonder just how wide the dynamic range of the original scene really was.
