Re: [Lcms-user] HDR

[Pekka P. <pek...@ha...>]

On Tue, 19 Mar 2024 17:56:42 +1100
Graeme Gill <gr...@ar...> wrote:

> mar...@li... wrote:
> 
> >  I think the issue here
> > is HDR is not well supported by ICC workflows, highlights and values above
> > L* 100 of D50 are seldom discussed in the 4.4 ICC spec. For BT.2020/PQ,
> > which profile I'm attaching this is quite evident. Lcms can deal with it on
> > unbounded mode, but if you feed a RGB -> Lab transform, for
> > RGB=(255,255,255) you will find L*=523!! This is not encodable in any CLUT
> > unless you provide enough headroom.   
> 
> In my view the elephant in the room with regard to HDR standards
> is the lack of explicitly dealing with the diffuse white.
> [ As best I understand it this is a result of rushing mastering
>   HDR standards into consumer products. ]

I suppose you refer to various HDR "systems" like BT.2100 PQ and HLG
defining their diffuse white as a specific code point, so it does not
need explicit communication as long as you know what system you are
looking at?

Then, PQ system defines "absolute" luminance by its TF, which is
relative to its reference viewing environment. HDR static metadata
tells the mastering display color volume (or not) to give the bounds on
luminance and gamut.

HLG system uses relative luminance signal, and defines a luminance
conversion function to map the signal to given display capability. The
result is again relative to reference viewing environment.

Neither specifies how to adapt the image to a different viewing
environment.

Does this match your understanding?

Our draft of Wayland protocol extension currently stops at delivering
the HDR static metadata. We think that we also need to communicate
expected or reference viewing environment somehow, and perhaps diffuse
white level in order to pin everything down in the image content. Those
may be defined by the "system" the content was made for, if nothing
else.

Then let the end user adjust a couple of simple knobs to get the image
right for their display and viewing environment. That will affect the
final diffuse white level on display, which affects also the HDR
headroom.

> This then flows through to a lack of standards in things like
> ICC profiles for HDR displays. Simply determining a PCS diffuse white point for
> a given ICC defined HDR space lets you trivially convert to/from
> SDR, and not have to even worry about using ICC V4 to represent
> above PCS white values. This also means that SDR mappings
> are not hard coded into the profiles, and can be set by the user
> to suite their viewing situation and/or the source material.
> Levels above diffuse white can also be well managed in terms
> of compressing highlights to fit the range of the display,
> or applying tricks like highlight extrapolation from SDR sources.


Thanks,
pq