On Wed, 22 Sep 2021 11:06:53 -0400 Harry Wentland <harry.wentland@xxxxxxx> 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@xxxxxxx> 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 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 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. Thanks, pq
Attachment:
pgpS_iUFp5x61.pgp
Description: OpenPGP digital signature
