#131 HDR files possibly malformed in some way

Luminance_HDR_2.3.0
open
Davide
Program (114)
5
2013-07-30
2012-05-29
No

Hi

I've had serious issues using HDR files in the HDR and EXR formats in Autopano Giga, a panorama stitching program.
Please take a look at this issue and comment whether there is anything unusual about the HDR files Luminance HDR creates... perhaps they're using a different metadata tag of some sort that fools Autopano into clipping them?

http://www.kolor.com/forum/t14910-apg-2.6.3-exr-and-hdr-files-are-not-opened-correctly

Luminance-HDR 2.3.0-beta1

Discussion

  • Franco Comida

    Franco Comida - 2012-05-30

    HDR images are what they are, they cannot be displayed correctly on a computer monitor or even printed, you must tonemap them first. In Luminance HDR you can move the blue slide on top of the HDR image to select a different range of light intensity, I guess there is no such option in your stitching program, this is why the sky appears clipped. Just stitch the panorama, save the result, load it again in Luminance and do the tonemappiing.

     
  • Anonymous

    Anonymous - 2012-05-30

    Thank you for the lecture, I'm quite familiar with what they are. Please re-read the bug report.

     
  • Davide

    Davide - 2012-05-30

    @teamower: I might have a justification of why this thing is happing. And it would justify also why you can read EXR file generated with Luminance HDR into Picturenaut and viceversa. However, I am not sure we can call it bug.

    In my opinion, the problem arise because PS, Autopano (and some other programs I guess) expect the input data to be in the range [0,1] of the float. While this assumption is common (and in fact, [0,1] is the interval with the highest precision achievable in float), many tonemapping algorithms would not work really well if the input range is that narrow. This is the reason why, after the merge operation, Luminance HDR stores into EXR or RGBE all the values without performing any scaling. So, instead of [0...1], your EXR will hold also funny values, (for instance 1000). Of course, tools that expect this range, will do their own scaling for visualization porpoises (Luminance HDR does that, Picturenaut might, I don't know for sure), while others will display these big values as pure white or with some colour artefacts (a problem we had in Luminance HDR as well).

    Solution? Well, it's hard to say. I'm pretty sure EXR supports a tag that contains the scaling factor, so numbers can be stored in the range [0,1] and then, during the read, be scaled back to the original range (I am pretty sure the rendering engines that work with EXR do something similar). I am not aware whether such an option is available in RGBE or LogLuv TIFF: it would be interesting to find out. This could solve the problem in many scenarios, except those programs that will NOT read the custom tag, but DO expect a larger range.

    I hope what I wrote makes sense.
    Best,
    D.

     
  • Anonymous

    Anonymous - 2012-05-31

    Thank you very much for your reply Davide. AlexandreJ of Autopano has replied in the forum I linked to.

     
  • jedfrechette

    jedfrechette - 2013-07-30

    Clamping the range to 0-1 is definitely a bad idea. On the other hand, the values used by Luminance are pretty non-standard as well. See the quote below from the OpenEXR technical documentation.

    With this linear relationship established, the question remains, What number is white? The convention we employ is to determine a middle gray object, and assign it the photographic 18% gray value, or .18 in the floating point scheme. Other pixel values can be easily determined from there (a stop brighter is .36, another stop is .72). The value 1.0 has no special significance (it is not a clamping limit, as in other formats); it roughly represents light coming from a 100% reflector (slightly brighter than paper white). But there are many brighter pixel values available to represent objects such as fire and highlights.

     

Log in to post a comment.