Sébastien, ok to push it then?
Edit: I just pushed the fix.
1 Like
Hmmm… in fact I tried on a new set of 3 images, and it looks like the final DNG is mostly as dark as the darkest bracket. I’ll upload the set to filebin.
Edit: here’s the link to the images Filebin | gk09dzala7hlp1ec
Or maybe I don’t know how HDRMerge works really… When I open the DNG, it looks exactly like the darkest frame, but when I push the DNG by +4EV I get the same low noise in the shadows as the brightest frame, while pushing the darkest frame by +4EV brings out a lot of noise.
So, I guess it works, and that all I need to push the shadows in the merged DNG?
1 Like
Seems to work fine then.
I was expecting that the merged DNG would open with more of a “merged look” already, without the need to push the shadows.
A “merged look” would be tone-mapping. HDRMerge produces raw files with a high dynamic range, it does not alter them.
If I compare the HDR DNG in RT to any of the source images used in the creation of that DNG, I can make the HDR DNG perfectly match any of the source images by using exposure compensation alone. That’s really cool. It means one can save a lot of disk space by merging all source raw files into one, and can still, for example, output {-4EV, -2EV, 0EV, 2EV, 4EV} from that single HDR raw file into TIFFs for use in Luminance HDR.
Yes, it was just a lack of understanding about what the merged DNG is. That’s great indeed, and I’m so happy to have this possibility offered now. Not only it can save space like you said, but it saves also some processing time for scenes with a dynamic range larger than what the sensor can handle.
I read the “manual” in the read me file at github, but it doesn’t explain how to use the files we get from HDRMerge.
1 Like
I’ll submit a pull request for that shortly 
2 Likes
I have a question, still regarding x-trans raws: I saw that the alignment of input files is made by translation by increments of 2 pixels because of the Bayer pattern… but x-trans being another CFA, what is consequence of moving frames by increments of 2 pixels?
Hopefully this is helpful: Update readme to say what to do with output images by paperdigits · Pull Request #121 · jcelaya/hdrmerge · GitHub
1 Like
@paperdigits thanks for the addition to the documentation. However, I think we need to go further. Indeed, the user is likely to know that they need to further process, because the resulting file is a raw file, and raw files always need to be processed. What is lacking in my opinion, is at least a simplified explanation of what can be done from the resulting DNG. For instance, I was (foolishly) thinking that when opening the DNG the shadows that are displayed in RT would be the shadows from the bright exposure, the highlights those from the dark exposure, and that the processing left would more tweaking the local and/or global contrast. Maybe I’m not the only one to be foolish like that, and explaining what to do would prevent seeing foolish questions in the future?
As for where such a how-to should be written, I don’t know.
Why not on the main PIXLS.US site? 
Yes @Morgan_Hardwood I read earlier, but while it gives details how to work within HDRMerge, it doesn’t cover what to do next from the output DNG. It’s not the role of HDRMerge’s manual to tell us what to do next, but maybe it could point to specific tutorials for DT and RT… to be written on pixls.us as suggested by @paperdigits?
1 Like
It’s not up to date too. For example the custom white level option is missing.
I haven’t read the manual 
Reason being is that when I read it, I “have” to update it, along with the website… I agree that it should lead the user to the next step, and that next step is RT’s “HDR Tone Mapping” tool: http://rawpedia.rawtherapee.com/HDR_Tone_Mapping
2 Likes
Indeed that’s what I found out, simple and effective.
1 Like