Merging 3 brackets?


I’ve merged 3 brackets; -2EV, 0, +2EV. HDRMerge has used the +2EV as a based line (less noisy). The sky is obviously blown out and the merging uses the 0EV bracket (the -2EV hasn’t been used).
I haven’t removed any pixels; I’ve left the default merging. Then saved it to 24 bits and in RawTherapee the recovered sky is displayed in pink.

If I open the 0EV or the -2EV raw files in RawTherapee; there is no blown highlight.

(Ingo Weyrich) #2

@anubis Perhaps the same Issue?

(Morgan Hardwood) #3


…how do you determine the threshold accurately?

HDRMerge: latest from master (09/08/2016)
RawTherapee: 4.2.1002 (latest RPM for Fedora 23)

There is nothing special about the shots, I just want to play around with merging and raw edition.

HDRMerge AppImage - first experiment
(Ingo Weyrich) #5

@anubis Using a white level from here should be a good startig point. Just search for your camera.

Edit: Search for Canon EOS M.


…yep I’ve tried some values for the M3 and same issue… I’ve posted the 3 raws if somebody want to play.

(Ingo Weyrich) #7

@anubis I’ll test now with your files

(Ingo Weyrich) #8

@anubis I tried hdrmerge with your images. One problem with your files is, that there is no information about aperture in exif. This leads to some NAN values in processing the files. The aperture value normally is used to identify the EV of the raw files (there are cameras which change aperture while bracketing). But for your case (no aperture value or aperture 0) I can try to use a dummy value (2.8 for example) instead. I’ll create an issue and see what I can do tomorrow. Today it’s still too hot here in Germany to do serious work…



I’ve shot with a manual lens Canon FD 24mm 2.8; the aperture was set at f11.


Does HDRMerge not detect brightness directly from the images?

Sample many points, ignore value pairs where there is highlight clipping?

(Ingo Weyrich) #11

If the aperture is constant for all raws of the merge, its value shouldn’t play a role (with the exception of aperture 0 in your case, which seems to lead to division by zero). Unfortunately Canon cams don’t allow to set the aperture (even max aperture would be useful) for manual lenses. I understand that it’s not possible for Canon cameras to store the current aperture in exif when using manual lenses, but storing the max aperture maybe would be possible technically and probably help in this case.

(Ingo Weyrich) #12

@CarVac Currently HDRMerge detects brightness from exif values afaik. Sampling many points would be a solution with the exception of misaligned images.

(Flössie) #13

Ingo, that’s strange, because I often stack shots taken with a fully manual lens on my Canon, and I’ve never run into this issue. And yes, aperture shows as f/0.0 in various EXIF tools.

HTH, Flössie!

(Ingo Weyrich) #14

@anubis It turned out that you have to use a more recent version of libraw for files from your camera. Using latest HDRMerge and libraw 0.17.2 I got this result, whick looks ok to me.


I’ve tried to alter the exif values and same issue…

exiftool -verbose -ExifIFD:FNumber=11 -ExifIFD:ApertureValue=11 -ExifIFD:FocalLength=24 -Canon:MaxFocalLength=24 -Canon:MinFocalLength=24 -ExifIFD:LensInfo="24mm f/2.8" -ExifIFD:LensModel="Canon FDn 24mm f/2.8"

which tags are you reading from?

(Ingo Weyrich) #16

Floessie, you’re right. The aperture 0 is not the problem. But nevertheless I’ll use a ‘default’ aperture instead of 0 to avoid these annoying finf EV:-inf in console when running hdrmerge -vv


@heckflosse: thanks a lots; I’ll update my version of libraw

(Ingo Weyrich) #18

To avoid annoying output when using HDRMerge in verbose mode -vv, I just pushed a commit which uses aperture f8 if the aperture reported by libraw is invalid.