Black DNG output from HDRMerge

Hey All,

I’ve been having some great success with HDRMerge except for a few image sets which, for some reason, are exported as full black. Here’s a screenshot of 17 files, 2 of which have come out black.

All the images were taken on a Tripod with exposure bracketing so they should be similar enough to not cause issues. I’ve tried changing options like alignment but not found anything to work.
The problematic files are also only 1.3mb and there no data when loaded into photoshop (just full black)

Here is one of the sets of images: Problematic RAWs – Google Drive

Any help?

Can you post the HDRmerge outputed image too?

Sure thing, I’ve added it to the folder linked above.

I just noticed if I omit the first image from the set (1650) the merge is ok

@Congles Welcome to the forum!

This could be due to a number of reasons.

One being that HDRMerge is giving all the weight to the dark or black frames. In this case, you need to mask out the frames that don’t give you any data or not enough of it to matter.

The other possible explanation is that the DNG is incompatible with PS. In this case, I would suggest that you try opening it using RawTherapee or darktable, which are apps we support here. DNG is an Adobe standard, so we should figure out where the incompatibility exists.

Lastly, HDRMerge isn’t being actively developed but if there is a real bug I am sure that someone will get on fixing it. For that to happen, we need more info and context to the problem.

Thanks @afre

It definitely isn’t a compatibility issue - the file should be much larger than 1mb, however I did test the file in RawTherapee as you suggested and it is still black. :frowning:

I don’t know, it merges perfectly fine for me.
What version are you using? Have you tried the appimage?
https://github.com/jcelaya/hdrmerge/releases/download/nightly/hdrmerge_master_continuous-68-g69e3c5f_20191005.AppImage

I’m using the latest windows build from the site (I think v0.5). I’m not sure about appimage usage on windows, if you have a link to guide me on how to make it work that would be appreciated.

I’ll give it a go in the morning as it’s late here now.

In that case, since there in no Windows installer of the master branch available you’ll have to compile it from source by downloading this source code:
https://github.com/jcelaya/hdrmerge/archive/nightly.zip

And following these compilation instructions for Windows (click “show original”):

Alright, good night!

Before building yourself (I suggest doing it on mingw64 since it has all the dependencies included, apart from ALGLIB), you could try the 0.6 tag build here first: HDRMergeNightlyBuilds/ – Keybase.pub

If you do end up building using mingw64, you’ll need to update data/setup.nsi for the newer library versions that mingw64 now ships (or disable building the installer…):

image

That is definitely an old one. Last I checked (a year ago), the nightlies were a little behind but that may have been rectified…

Thanks for the help guys! @kmilos your link thankfully saved me from having to figure out the compile process myself (I come from an artist background, not a programming one so I didn’t like my chances).

The problem is fixed thankfully and I’m even able to batch process files!

Now I’m onto the next issue which is managing colour differences when stitching in PTGUI. If anyone has experience using this HDR merge with PTGUI I’d appreciate some advice!

1 Like

Oh man, you’ve shot with auto white balance didn’t you?
When I do 360 panos, I shoot HDR but on fixed white balance and then if something doesn’t match I just eyeball it.
You can fix the white balance in Darktable.

haha no I fixed the white balance at 5600, but the camera is set to auto bracketing (5 shots, 3EV’s apart), which does definitely cause some variations. It’s actually something else happening when I merge them in PTGui though… give me the weekend to go take some new shots and I’ll share a screenshot of what I mean.

1 Like

Then the auto exposure is the problem?
Everything needs to be fixed. WB, aperture, exposure time, focus. I don’t bracket, I do entire pano at one exposure, then repeat two-five times at different one.

Quite possibly, I have to do some more testing. It’s not possible for me to use the same process you do as the clouds here move too quickly :frowning:

Right, I’ve made a robot with arduino an couple of servo motors that does the entire pano in under a minute. I’d also do bracketing if I had to do it all by hand.

It sounds like you know the process well…

What kind of values would you want to get for the sun in your HDRI?
Pixars reference HDRI has a value of 30,000 but I feel like that is highly unnecessary, but wondering what you’ve been able to achieve? I’m limited by time too as I mentioned, the clouds move so quickly.

What is this value you speak of? Colour temp, white point, peak luminance, …?

Peak luminance I would say, when you sample the floating point EXR in nuke at the hottest spot, you’ll get a value. Pixars reference HDRI shows 30,000 although that’s way higher than needed for VFX work, but is probably good/required for lookdev and marketing etc

For an infinitely bright light source, relatively, compared to everything else, one sets an arbitrary high number. HLG / PQ are often set at 10,000. It also depends on the theoretical peak of a display.