Re: Converting HDR to sRGB for Display

Agreed.

From: Chris Seeger <Chris.Seeger@nbcuni.com>
Date: Monday, February 7, 2022 at 12:06 PM
To: Lars Borg <borg@adobe.com>, Simon Thompson <Simon.Thompson2@bbc.co.uk>, "public-colorweb@w3.org" <public-colorweb@w3.org>
Subject: Re: Converting HDR to sRGB for Display

The hard part here is that a sophisticated knee is necessary to properly protect highlights when converting from HDR to SDR.  Without the knee, a lot of detail is lost.

If you don’t use a knee, the result is much darker imagery.

Chris Seeger

From: Lars Borg <borg@adobe.com>
Date: Monday, February 7, 2022 at 4:35 PM
To: Simon Thompson - NM <Simon.Thompson2@bbc.co.uk>, public-colorweb@w3.org <public-colorweb@w3.org>
Subject: [EXTERNAL] Re: Converting HDR to sRGB for Display
You don’t want this to depend on values on the canvas or anywhere.
The (canvas) values are dynamic. Any new action or time can result in new values.
Including being in range or out of range 0-1.
It would be awkward to implement and an awkward user experience if there is a color change as you cross the boundary.
Also, the script may want to know upfront if extended range is supported.
Thus the space selection needs to be made explicitly.

Somehow the below seems more complicated than I would expect.
Many non-web apps and OSs already display HDR/SDR content including diffuse white level and clipping and I don’t want yet another method for doing it. Unwanted because a/ appearance doesn’t match existing display paths, b/ yet another code path to maintain, c/ yet another non-standard solution, adding to industry confusion.

Are there any standards-based solutions for displaying mixes of SDR and HDR that we can apply here?
If not, are any of the already existing proprietary solutions candidates for standardization?

Lars

From: Simon Thompson <Simon.Thompson2@bbc.co.uk>
Date: Monday, February 7, 2022 at 6:31 AM
To: "public-colorweb@w3.org" <public-colorweb@w3.org>
Subject: Converting HDR to sRGB for Display
Resent-From: <public-colorweb@w3.org>
Resent-Date: Monday, February 7, 2022 at 6:30 AM

Hi all,

I’ve been giving some more thought to the issues highlighted in the last call.

It would be preferable if the connection space contained only data within the sRGB range to just map it directly to sRGB.  However, if the connection space has values outside sRGB (i.e. outside the range 0-1) it would be preferable to map the connection space to sRGB.

Is it possible to test the max and min values of the RGB data?

To connect the connection space with HDR data to an sRGB monitor, one can convert to HLG then apply:

function tonemapREC2100HLGtoSRGBdisplay(r, g, b) {
  const systemGamma = 2.2;
  const r1 = simpleTransform(r, systemGamma);
  const g1 = simpleTransform(g, systemGamma);
  const b1 = simpleTransform(b, systemGamma);
  const [r2, g2, b2] = matrixXYZtoSRGB(matrixBT2020toXYZ(r1, g1, b1));
  const r3 = simpleInverseTransform(r2, systemGamma);
  const g3 = simpleInverseTransform(g2, systemGamma);
  const b3 = simpleInverseTransform(b2, systemGamma);
  const [r4, g4, b4] = limitTosRGBGamut(r3, g3, b3);
  return [r4, g4, b4];
}


Secondly, if the Operating System requires the diffuse white level to be scaled to a user defined value, do we need to:

·         create a method to scale the luminance, and
·         ensure that the highlights aren’t clipped when displayed on a monitor which can not manage the matching peak luminance value?

Best Regards

Simon

--
Simon Thompson MEng CEng MIET
Senior R&D Engineer
BBC Research and Development South Laboratory