How to normalize multi-channel exr image?

[ittim4]

A) Need to normalize RGB 3 channel "half-float" linearized image..which can have pixel values greater than 1. What is recommended practice to normalize such half float exr image?
option 1: sum = r+g+b and then normalized_r, _g, _b = r/sum, g/sum, b/sum
option 2: max = max(r,g,b), and then normalized_r,_g,_b = r/max, g/max, b/max
Is it option 1 or 2 or something else?
B) Would be great if you can also explain: what does "exrdisplay.exe -n" option does for normalization? Also, I see when "-n" is used, hdr images look better and "exposure" value is auto adjusted compared to without "-n" option in which case exposure value is set to 0. Can you comment how exposure value is calculated when "-n" option is used for normalization?

[peterhillman]

The code that exrdisplay uses is here:
https://github.com/openexr/openexr/blob/master/OpenEXR_Viewers/exrdisplay/scaleImage.cpp#L195
which is like your option 2, but it remaps min(r,g,b) to 0 as well as mapping max(r,g,b) to 1. It ignores infinities and not-a-number values when finding the min/max values. Perhaps the min mapping to 0 helps to make the image look better for exposure.

Your option 1 removes intensity variation from the image, as it ensures every pixel's RGB values sum to 1. This will make the image look very strange. A Black and White image will disappear completely - every pixel will be the same shade of gray. That's a very different result to your option 2.
(Negative values may cause issues for both your options, though)

Without more information about why you need to normalize it is hard to advise. The OpenEXR developers mailing list (https://lists.aswf.io/g/openexr-dev/) is read by people who may have better suggestions than me!

[ittim4]

Great, thanks a lot peterhillman! Yah, code link is helpful!

Regarding normalization, couple of angles here:
a)I have few exr images which am trying to view using "exrdisplay" with and without "-n" option for normalization. Without "-n", image seems to be darker and exposure value is always set to '0'. But with "-n", it seems "exposure" value is auto adjusted and image seems more appropriate. Can you help how "-n" or normalization is impacting "exposure" value while using "exdisplay" utility? Would be great if you can point to a code for this auto-tuning of exposure value based on normalization.
b) Thinking of normalizing image into [0,1], as wanted to experiment with PQ/gamma encoding.

[peterhillman]

If you specify "-n", you get different default values for 'kneeHigh' and 'exposure', but those defaults don't change based on the pixel content, so there's no "auto-tuning" as such. They are just different defaults in the code (they are in main.cpp).
In your case, I guess simply remapping the values to a [0,1] range seems to make things look better, but that won't be true of all images.

For PQ-style HDR and log encoding, typically some constant value is taken as the '1' value, rather than analysing it from an image. So you could decide a value of 8.0 in linear gets mapped to 1. Anything brighter would be clipped to 1. That makes the mapping consistent, which is important for video. If you normalized every frame of a video to [0,1] separately, then nighttime images would come out just as bright as daytime ones and you'd get a very flickery result as the maximum value changed.

[ittim4]

Thank you..that helps a lot! Interesting that "-n" defaults for 'kneeHigh' and 'exposure' happened to work great for my images; wondering if they were arbitrary or based on some study. Also, am thinking if I can explore more on adding option for auto adjusting exposure based on image for better viewing experience as an optional feature. Good to know if you happen to have any suggestion or good starting point.

Thanks for comments and insight into handling PQ-style encoding part. One part of the problem is: am still learning to interpret the original non-normalized values in exr file which are essentially linear, half float values but don't know if there is a way to interpret or translate these values in terms of actual "nits" represented by these values. Per my understanding, there is no metadata or header info that helps guide how, say this 8.0 value in exr (linear, half float, scene referred value) represents actual 'nits' for corresponding scene element. For e.g. if "8.0" translate to say 8.0 x k nits, where 'k' is luma scale factor probably known at capture time for the creator, but per my understanding, this 'k' or any information that helps translate these linear half float values to absolute 'nits' of content is not part of header and hence just having exr file may not be sufficient to find 'nits' represented by the content in exr file, rt?
Am still learning to interpret, so would be happy to get enlightened or pointed to right resource. It wasn't clear to me yet per description in tech introduction doc here.

[meshula]

If you're using the -n option, you're into the realm of tonemapping. You might be interested in exploring this project: https://github.com/meshula/tonemapper

The first section (Scene Referred Images) of this document: https://www.openexr.com/documentation/OpenEXRColorManagement.pdf explains that pixels in an openexr image are measured relative to each but not to any absolute value. It's worth a read.

[ittim4]

Thanks a lot meshula for pointing to document and tonemapper project as well!

Last bit of question I have was with related to 'exrdisplay' utility with or without normalization. It is clear from doc here and code here that it can do gamma encode to show exr image appropriately on 8b display. But, how about when connected to 10b HDR monitor wih hdr os mode on? In this case: I couldn't find the exact code if any for 10b pq encode, but it seems like it might just be doing gamma encode only but image looks reasonably similar or slightly better. Would be good to hear if anyone has experimented this and has any thoughts or resources to look at. Thanks in advance!

[ittim4]

Thanks all for feedback; can close this for now as main question has been answered.