Re: Incorrect Algorithm and mDCv for HLG (From last night's meeting)

On Fri, 29 Sep 2023 15:27:12 +0000
Simon Thompson - NM <Simon.Thompson2@bbc.co.uk> wrote:

> Hi
> 
> Apologies for the brief reply, I’m on my phone.
> 
> BT.709 and HLG are not display referred by the definition that ISO
> uses, which is the one that almost all other standards bodies
> reference.

Hi Simon,

thank you for the reply.

Indeed, I have realised that my confusion comes from terminology.

> For a signal to be display rereferred, the signal has to represent
> the exact expected output of a display.  Neither HLG nor BT.709 do
> that – they refer to the scene and the display is free to apply its
> EOTF (complete with adaptations for screen and ambient luminance) and
> in the case of a TV, the manufacturer’s “look”. 

I think my mistake was assuming that if you adjust the image look while
looking at a grading/mastering display, you'd be adjusting the image and
defining how it needs to be displayed, making it display-referred.

After reading a section of

https://library.imaging.org/admin/apis/public/api/ist/website/downloadArticle/cic/10/1/art00021
Kevin Spaulding, Requirements for Unambiguous Specification of a Color Encoding: ISO 22028-1,
IS&T/SID Tenth Color Imaging Conference

I understood that you're not adjusting the image, but modifying the
scene of a scene-referred signal. The displaying of the image
remains... undefined.


> So you can put the
> same HLG signal in to 500, 1000 and 4000 nit monitors, they’ll look
> perceptually similar, with similar levels of detail in the shadows
> and mid-tones and saturation, but they will be different brightnesses.

If I understand right, the key for display-referred is that the
signal-to-radiance function must be fixed by the signal definition.
Since HLG EOTF includes the HLG OOTF which is parameterised by the
actual display and viewing conditions, it is variable and not fixed.
BT.709 says to decode with BT.1886 which also is parameterised, and not
fixed.

> HLG is designed to be a very natural looking image – a bit like
> looking out of the window.  This does not match what sports or drama
> productions use, hence the in-camera artistic controls.  However, the
> signal is still referred to the scene rather than a single monitor
> and can be adapted for any display.  There are use cases where no
> artistic controls are used and accurate colours are required – such
> as medical imaging – so it’s important that any software
> implementation can handle this.  (ISO split this into something like
> “scene referred” and “scene referred with scene chromaticies”)

Right. For Wayland, the desire to support ICC workflows and rendering
intents should ensure we can also keep accurate colorimetry when wanted.


Thanks,
pq