hdr_generation_alignment example: HDR output is unexpectedly overexposed

[jamesplease]

What am I seeing?

When I run the hdr_generation_alignment example, the produced HDR image is exposed with intensity at +7/+9 stops for all pixels. A few environments with reasonable tonemapping implemented (Photoshop/Unity) render the output as pure white on SDR screens.

To produce a more balanced result, adjusting the example's exposure in Photoshop by about -10 is required.

What would I expect to see?

I expected the example to output a more balanced HDR image to serve as a representation of the kinds of "correct" inputs that yield "correct" outputs.

Is this a bug, or is the intended result of this example that the HDR image would be this exposed?

By more balanced, I specifically mean:

• Standard SDR tonemapping would capture detail of the image, rather than showing all white
• A reasonable level of bloom applied on the image would yield the kind of result most people would expect, with bloom most prominent in the sky (at the moment every pixel will be lit up, like the image is of a bright light bulb)

More info

• Compiled on Windows 11 using cl \HEsc main.cpp

[banterle]

Piccante given the EXIF information such as shutter speed, aperture, and ISO tries to calibrate the HDR image to have scene-referred values (i.e., cd/m^2); these values are closed as much as possible (with some degree of approximation) to what you would get when measuring using a luminance meter. For example, in the real-world, an office white wall with artificial lighting would have a value of 80.0 cd/m^2.

I expected the example to output a more balanced HDR image to serve as a representation of the kinds of "correct"
inputs that yield "correct" outputs.

This "correct" is not physicially correct. HDR is about recording real-world lighting.

Standard SDR tonemapping would capture detail of the image, rather than showing all white

It is not clear if you tone map the image or you just open it on Photoshop and you change exposure and gamma encoding.
What do you mean with standard tone mapping?

A reasonable level of bloom applied on the image would yield the kind of result most people would expect, with bloom
most prominent in the sky (at the moment every pixel will be lit up, like the image is of a bright light bulb)

There is no bloom filtering as in games when merging HDR images.

[jamesplease]

Thanks for the reply!

What do you mean with standard tone mapping?

No modifications to the image at all. Just viewing it in an application like Photoshop.

There is no bloom filtering as in games when merging HDR images.

I know — I was describing what happens when you do apply bloom to the output.

—-

If I follow what you’re saying, it sounds like HDRis on websites like https://hdri-haven.com/ must have been modified to no longer be physically accurate? Many of those have way brighter sources of light (ie including the sun) but they’re able to be viewed on SDR displays without any modifications like reducing the exposure.

[banterle]

If I follow what you’re saying, it sounds like HDRis on websites like https://hdri-haven.com/ must have been modified to
no longer be physically accurate?

I have no idea of the processing happening there. Re-exposing HDR images or radiance maps is a common practice amonst photographers in order to visualize something on classic monitors and apps. However, this leads to losing important lighting information. It depends on what you want to do with HDR images; if you need physically-based values for lighting simulation then rescaling is not good. There are approximations to guess the original scaling.

[jamesplease]

I appreciate the replies @banterle . You're clearly far more knowledgeable about HDRs than I am, so I'll close this issue out and assume everything is working as intended.

I still am surprised that the output of this lib is orders of magnitudes more exposed than any other HDRi I've ever encountered in my career (HDRs from different sources/contexts/etc.). I don't know enough about HDRs to say more, but tooling pipelines work well with all of these other HDRs without any modifications but this example from Piccante is as bright as the sun in those pipelines (Unity/Photoshop/most likely Blender as well)

However, for my current use case I'm not doing physically accurate rendering -- I just need the result to look good -- so I can manually adjust the exposure of the output from this lib.

Thank you!