is hugin_hdrmerge broken?

[kfj]

I'm trying to use hugin_hdrmerge on a bracket of three images, but I'm getting an error saying that the images are 'not an image file', and subsequently the program crashes:

hugin_hdrmerge -o hugin.exr IMG_308?.JPG 

  
caught exception: Cannot read image file "IMG_3086.JPG". File is not an image file.

Abgebrochen (Speicherabzug geschrieben)

Am I doing something wrong or is hugin_hdrmerge broken? I tried an older build (some time last year) and one fresh from source as of today, with the same result - same for TIFF input.

Kay

[T. Modes]

kfj schrieb am Mittwoch, 30. Juni 2021 um 11:39:05 UTC+2:

Am I doing something wrong or is hugin_hdrmerge broken?

Hugin_hdrmerge is intended to merge linear exr files only - not for LDR images. And for this use case it works.

I added a better error message to make it clearly and prevent the crash.

[kfj]

Thanks for the quick fix! I thought it would do the registration and photometric optimization of the input images (like align_image_stack), and then merge them to HDR (the man page is a bit thin). I converted my input to openEXR format, and now I found the next problem:

/usr/local/bin/hugin_hdrmerge -v -o hugin.exr ./IMG_308?.EXR

caught exception: Precondition violation!

File with original pixel weights (./IMG_3086_gray.pgm) is missing

(/home/kfj/src/hugin/src/hugin_base/vigra_ext/ReduceOpenEXR.h:72)

Abgebrochen (Speicherabzug geschrieben)

I saw hugin produce such pgm files, and I could never figure out why they would be needed: the exr should have all the nececssary information, because it holds linear RGBA. What's the pgm good for?

Kay

[T. Modes]

kfj schrieb am Mittwoch, 30. Juni 2021 um 23:05:13 UTC+2:

I saw hugin produce such pgm files, and I could never figure out why they would be needed: the exr should have all the nececssary information, because it holds linear RGBA. What's the pgm good for?

In Hugins HDR workflow all input images are remapped to the output projection. In the same time they are converted into the same linear colorspace - it corrects the exposure, vignetting (and also white balance). But then the information about under- and over exposed pixels is lost. This information is transferred to hugin_hdrmerge with the _gray.pgm files and helps to merge the individual images.

[kfj]

Okay, now I understand, thanks for the clarification. Lux combines the remapping and HDR merging 'under the same roof', so the overexposedness can be detected in the pixel pipeline and does not need to be stored to an intermediate file. I had hoped to suggest hugin_hdrmerge as an alternative to lux users who found lux too 'automatic' for HDR merging, but I misunderstood what it does. So it's probably better to suggest software like align_image_stack to them, as an alternative to the use of "lux --hdr_merge=yes my.pto" which hdr-merges the images in a pto in one (automatic) go.