On 2021-09-23 9:40 a.m., Harry Wentland wrote:
On 2021-09-23 04:01, Pekka Paalanen wrote:
On Wed, 22 Sep 2021 11:06:53 -0400 Harry Wentland harry.wentland@amd.com wrote:
On 2021-09-20 20:14, Harry Wentland wrote:
On 2021-09-15 10:01, Pekka Paalanen wrote:> On Fri, 30 Jul 2021 16:41:29 -0400
Harry Wentland harry.wentland@amd.com wrote:
<snip>
+If a display's maximum HDR white level is correctly reported it is trivial +to convert between all of the above representations of SDR white level. If +it is not, defining SDR luminance as a nits value, or a ratio vs a fixed +nits value is preferred, assuming we are blending in linear space.
+It is our experience that many HDR displays do not report maximum white +level correctly
Which value do you refer to as "maximum white", and how did you measure it?
Good question. I haven't played with those displays myself but I'll try to find out a bit more background behind this statement.
Some TVs report the EOTF but not the luminance values. For an example edid-code capture of my eDP HDR panel:
HDR Static Metadata Data Block: Electro optical transfer functions: Traditional gamma - SDR luminance range SMPTE ST2084 Supported static metadata descriptors: Static metadata type 1 Desired content max luminance: 115 (603.666 cd/m^2) Desired content max frame-average luminance: 109 (530.095 cd/m^2) Desired content min luminance: 7 (0.005 cd/m^2)
I forget where I heard (you, Vitaly, someone?) that integrated panels may not have the magic gamut and tone mapping hardware, which means that software (or display engine) must do the full correct thing.
That's another reason to not rely on magic display functionality, which suits my plans perfectly.
I've mentioned it before but there aren't really a lot of integrated HDR panels yet. I think we've only seen one or two without tone-mapping ability.
Either way we probably need at least the ability to tone-map the output on the transmitter side (SW, GPU, or display HW).
It is really interesting to see the quality of panel TM algorithm by specifying different metadata
and validate how severe loss of details which could mean no TM at all or 1DLUTÂ is used to soften the
clipping or 3DLUT( which has wider possibilities for TM)
To facilitate this development we may use LCMS proofing capabilities to allow simulate the image
view on high end(wide gamut display) how it may looks on low end
(narrow gamut displays or integrated panels)
I suspect on those TVs it looks like this:
HDR Static Metadata Data Block: Electro optical transfer functions: Traditional gamma - SDR luminance range SMPTE ST2084 Supported static metadata descriptors: Static metadata type 1
Windows has some defaults in this case and our Windows driver also has some defaults.
Oh, missing information. Yay.
Using defaults in the 1000-2000 nits range would yield much better tone-mapping results than assuming the monitor can support a full 10k nits.
Obviously.
As an aside, recently we've come across displays where the max average luminance is higher than the max peak luminance. This is not a mistake but due to how the display's dimming zones work.
IOW, the actual max peak luminance in absolute units depends on the current image average luminance. Wonderful, but what am I (the content producer, the display server) supposed to do with that information...
Not sure what impact this might have on tone-mapping, other than to keep in mind that we can assume that max_avg < max_peak.
*cannot
Right
Seems like it would lead to a very different tone mapping algorithm which needs to compute the image average luminance before it can account for max peak luminance (which I wouldn't know how to infer). So either a two-pass algorithm, or taking the average from the previous frame.
I imagine that is going to be fun considering one needs to composite different types of input images together, and the final tone mapping might need to differ for each. Strictly thinking that might lead to an iterative optimisation algorithm which would be quite intractable in practise to complete for a single frame at a time.
Maybe a good approach for this would be to just consider MaxAvg = MaxPeak in this case. At least until one would want to consider dynamic tone-mapping, i.e. tone-mapping that is changing frame-by-frame based on content. Dynamic tone-mapping might be challenging to do in SW but could be a possibility with specialized HW. Though I'm not sure exactly how that HW would look like. Maybe something like a histogram engine like Laurent mentions in https://lists.freedesktop.org/archives/dri-devel/2021-June/311689.html.
Harry
Thanks, pq