Common-ize the rec2100-pq/hlg/display-linear conversions

[ccameron-chromium]

This issue is to propose that we standardize all conversions to go through the rec2100 reference display (the 1,000 nit one).

This way, for converting to/from any of rec2100-pq, rec2100-hlg, and rec2100-display-linear, we follow the algorithm of:

• Convert the source color space to reference display luminance
• Convert from reference display luminance to destination color space (using the inverse function of the one used to convert to reference display luminance).

The conversions to reference display luminance are:

• rec2100-display-linear:
  • multiply by 203 nits
• rec2100-pq:
  • apply the PQ EOTF
• rec2100-hlg:
  • apply the HLG inverse-OETF
  • apply the HLG OOTF for a 1,000 nit display (gamma=1.2)
  • multiply by 1,000 nits.
• srgb:
  • apply the sRGB to linear transfer function
  • apply the matrix to convert from sRGB primaries to Rec2020 primaries
  • multiply by 203 nits

In this scheme the CSS color of (SDR) 'white' will map to a 75% HLG signal, or 203 nits.

When converting from any of rec2100-display-linear, rec2100-pq, or rec2100-hlg to any other color space (any SDR color space), then a default tone mapping must be performed to map the maximum HDR brightness (which is 1,000 nits by default) to the maximum SDR brightness (which is 203 nits by default), before converting to the SDR color space. To write this out explicitly, the algorithm is:

• Convert the source color space to reference display luminance
• Tone map the image so that its maximum luminance is 203 nits
• Convert from reference display luminance to destination color space
  • Divide by 203 nits
  • Apply the matrix to convert from Rec2020 primaries to the XYZD50 profile connection space
  • Convert to the target SDR color space

I have opinions about the exact contents of the second step (tone mapping down), but I'd want to ensure agreement on the general structure first.

[mdrejhon]

+1

Inventor of TestUFO here, founder of Blur Busters.

Thanks to all those doing wonderful work on HDR .

rec2020 CSS4 WCG + rec2100-pq CANVAS, can be a bit tricky to estimate nits from, without standardization; so muchly appreciated.

I have a big use case for this standardization + discovery.
In December, I am about to publish the world's first HDR display motion test.

Scientific testing needs to know the standardized behaviors.

Ideally, when you change things or commonize, we ideally need discovery of the reference nits. I think that Hollywood pages, display manufacturer testing pages, motion tests (me), gaming references, etc, should be able to unlock a reference mode within their browsers, even if it requires manual intervention (settings or permission etc).

• We need some reasonable modicum of discovery and access to native HDR colorspace for display performance testing, to know if the HDR nits are modified or not. We can detect if the browser can create HDR canvas, but we can't always reliably detect the reference nits for specific CSS4 colors. We can go by standards, but the browser is a fast-moving target.

• We need some reasonable modicum of discovery of the 'standard reference number' of nits in the CANVAs pixels. (at least somehow deduce the basic reference for a CSS4 color. Not actual nits since displays can remap and auto-dim when displayed static HDR pixels too long, etc. So I can display telemetry for display testing professionals. Obviously, displays will clip/etc to will, but there are high cost (>$10K) reference scientific/broadcast displays that displays as-is too.

And I can get brighter-than-#FFFFFF white just fine:

(P.S. For those unfamiliar, I am the founder of Blur Busters and TestUFO, the display motion testing website used by over 500 content creators and over 100 display manufacturers with over a million visitors per month that uses the dozens of different tests. I am in more than 30 peer reviewed research papers (including by big names like NIST-gov, NVIDIA and Samsung and others), because of my display testing innovations, Google Scholar: www.blurbusters.com/research-papers and Coles Notes: www.blurbusters.com/area51 ...)

Also, I saw the Sony 10,000nit prototype display at a past CES, so such displays exist, for certain special purposes. TestUFO is also used by gamers to show off their high-refresh rate displays, and I'd like it to be able to show off their existing 1000-2000 nit HDR capabilities (e.g. moving star scenes, simulated neon scenes, etc) for HDR motion comparative tests (local dimming performance problems etc). And some game-simulators may be added to certain TestUFO test patterns (There are over 40 now, and the number will rapidly exceed 100 in year 2024).

So, since this may help "mainstream HDR" by helping sell HDR displays, I'd like to make sure I'm following the web standards while getting scientific accuracy capabilities and demonstration capabilities (researchers, manufacturers, end users, gamers, etc), even if it is hidden behind a permissions API or hidden behind a configuration flag (e.g. unlocked native HDR that is unaffected by the Windows SDR slider).

BTW, this localhost page is going to be published to a public beta in December, and then commited to the main TestUFO site on time for CES 2024. (TestUFO has >1M visitors per month).

I plan to publicly announce the chrome://flags for the experimental web features for now -- but I would like to migrate as quickly as possible to standards.

BTW, TestUFO may be a useful inclusion in your testing suite, and I know some of the high-Hz Chromium team members uses https://www.testufo.com/animation-time-graph to see how much more accurate Chrome is than FireFox (currently). Chrome is able to do 480fps 480Hz displays perfectly, while FireFox falters.

Side-question: Is HDR going to be moved to a separate flag than Experimental Web Features soon? I'll automatically display customized instructions based on browser version detection. I hate having to detect useragent and version, but TestUFO features requires that for now.