RE: Alternative term to scene-referred to describe SDR imaging

Not sure about sensor-referred as the camera also has an effect – is there a problem with ‘camera-referred’?
_Craig

PS. The concept of distance pre-dates the invention of any measurement system 😉

From: Lars Borg <borg@adobe.com>
Sent: 12 January 2021 06:00
To: Craig Revie <Craig.Revie@ffei.co.uk>; Peter Occil <poccil14@gmail.com>; public-colorweb@w3.org
Subject: Re: Alternative term to scene-referred to describe SDR imaging

No. These standards predate the concept of image state, by many decades, so no such intent.

Legacy scene-referred is just as confusing.
Sensor-referred might be more meaningful.

Lars

From: Craig Revie <Craig.Revie@ffei.co.uk<mailto:Craig.Revie@ffei.co.uk>>
Date: Monday, January 11, 2021 at 7:47 PM
To: Lars Borg <borg@adobe.com<mailto:borg@adobe.com>>, Peter Occil <poccil14@gmail.com<mailto:poccil14@gmail.com>>, "public-colorweb@w3.org<mailto:public-colorweb@w3.org>" <public-colorweb@w3.org<mailto:public-colorweb@w3.org>>
Cc: Craig Revie <Craig.Revie@ffei.co.uk<mailto:Craig.Revie@ffei.co.uk>>
Subject: Alternative term to scene-referred to describe SDR imaging

Would it be true to say that the intent of these SDR standards is that the image is ‘scene-referred’? This seems to be implied in the documentation. If so, would the term ‘legacy scene-referred’ (or the use of some other qualifier) be appropriate?
_Craig
PS. I have changed the subject line which I hope will mean that this discussion moves to a separate thread

From: Lars Borg <borg@adobe.com<mailto:borg@adobe.com>>
Sent: 11 January 2021 20:40
To: Peter Occil <poccil14@gmail.com<mailto:poccil14@gmail.com>>; public-colorweb@w3.org<mailto:public-colorweb@w3.org>
Subject: Re: Thoughts on HDR

As per ISO 22028, display-referred is a subset of output-referred.
Note that output referred also includes printed media, so too broad a term when discussing what’s on display.
I don’t think we have a problem with referring SDR display colorimetry as display-referred.
The problem lies with the term scene-referred.

Lars

From: Peter Occil <poccil14@gmail.com<mailto:poccil14@gmail.com>>
Date: Monday, January 11, 2021 at 10:34 AM
To: "public-colorweb@w3.org<mailto:public-colorweb@w3.org>" <public-colorweb@w3.org<mailto:public-colorweb@w3.org>>
Subject: Re: Thoughts on HDR
Resent-From: <public-colorweb@w3.org<mailto:public-colorweb@w3.org>>
Resent-Date: Monday, January 11, 2021 at 10:34 AM


Compare with the term "output-referred", which is used in the International Lighting Vocabulary (rather than "display-referred") to mean an image state after color rendering has been applied.

--Peter
On 1/11/21 3:20 PM, Lars Borg wrote:
Please use a better term than scene-referred for 601 and 709 decoding.
What are some good terms to use?

Using the term scene-referred is quite misleading in the context of SDR TV.
Coding-wise, the SDR TV standards (601 and 709) are at best “camera-referred” rather than scene-referred. SDR cameras clip (with or without roll off), while scenes do not.
In addition, content broadcast in SDR TV encodings is almost always display-referred as it has been graded before encoded as a the SDR TV signal.
Thus, decoding the SDR TV signal using the inverse 601 or 709 TFs does not yield the original scene colorimetry.

You could potentially claim that HDR TV signals (and ACES) could be decoded to scene colorimetry. But AFAIK, HDR broadcast cameras also grade in camera, although maybe to a lesser extent. (ACES cameras supposedly do not)

Given that scene-referred reconstruction is more reasonable for HDR than for SDR, we need another term for SDR’s limited reconstruction. Or else we continue propagating a confusion that’s not helpful.
What are some good terms to use that indicates SDR’s limitation?

Lars

From: Craig Todd <CT@dolby.com><mailto:CT@dolby.com>
Date: Monday, January 11, 2021 at 9:04 AM
To: Simon Thompson <Simon.Thompson2@bbc.co.uk><mailto:Simon.Thompson2@bbc.co.uk>, "public-colorweb@w3.org"<mailto:public-colorweb@w3.org> <public-colorweb@w3.org><mailto:public-colorweb@w3.org>
Cc: Imane Mnie Filali <imane.mniefilali@bbc.co.uk><mailto:imane.mniefilali@bbc.co.uk>
Subject: RE: Thoughts on HDR
Resent-From: <public-colorweb@w3.org><mailto:public-colorweb@w3.org>
Resent-Date: Monday, January 11, 2021 at 9:04 AM

Simon,
Thanks for the clarification as to the 100 nit spec. Indeed it is NOT in BT.1886, but it is in BT.2035.
3.2         Reference white and reference black
Reference white (value 940) should correspond to 100 cd/m2 and reference black (Value 64) should be less than 0.01 cd/m2  . The waveform defined in Recommendation ITU-R BT.815 may be used to set these levels.

As to whether the SDR formats are scene or display referred, we could have a long discussion about that! In any case I don’t think either conclusion is needed for the work of this group.
Craig

From: Simon Thompson-NM <Simon.Thompson2@bbc.co.uk><mailto:Simon.Thompson2@bbc.co.uk>
Sent: Monday, January 11, 2021 8:44 AM
To: Todd, Craig <CT@dolby.com><mailto:CT@dolby.com>; public-colorweb@w3.org<mailto:public-colorweb@w3.org>
Cc: Imane Mnie Filali <imane.mniefilali@bbc.co.uk><mailto:imane.mniefilali@bbc.co.uk>
Subject: RE: Thoughts on HDR

Hi Craig,


Many thanks for your email.

I think that you’re correct that for video, the standards are relatively secure, but we also need to think about the environment and platforms on which video services are presented, e.g. BBC iPlayer, Netflix, Amazon Video, YouTube, Peacock. We need to ensure that all of the visual content, device capability discovery, interconnect signalling etc. is in place.  This will require harmonisation between specs from the W3C, HbbTV/ATSC, ICC and others.

To that end, could I introduce my colleague Imane to this group (cc’d) who has joined our team and will be working across a number of groups creating a gap analysis for our VOD platform.

For HLG, equations for adapting the display EOTF for differing ambient lighting conditions are published in ITU-R BT.2390, and we have recently undertaken a survey to understand the range of conditions people view television in.  Whilst it is true that the EBU monitors specification for HLG and PQ requires monitors to be at least 1000 cd/m2, HLG is not limited to 1000 cd/m2 and has been tested up to 4000+ cd/m2.

Finally, it’s worth mentioning that the SDR TV standards (ITU-R BT.601 and ITU-R BT.709) are in fact scene-referred and even the ITU-R standard for flat panel displays (BT.1886) does not specify a peak luminance in the normative sections.  There were a number of institutions such as the EBU that wrote calibration guides for professional displays.  There were a range of peak luminances and white points in use.  For professional use the peak was kept in the range 80 - 120 cd/m2 to prevent beam defocussing in the CRT, but in the home CRTs often ran much brighter than this (and the softness was accepted).  When using a CRT, adjusting the brightness control, conveniently adjusted both the black level and the transfer function, similar to what you have suggested for HDR; thereby ensuring subjectively similar images across a range of different viewing environments.


Best Regards

Simon



Simon Thompson
Senior R&D Engineer

BBC Research & Development

From: Todd, Craig <CT@dolby.com<mailto:CT@dolby.com>>
Sent: 10 January 2021 22:33
To: public-colorweb@w3.org<mailto:public-colorweb@w3.org>
Subject: Thoughts on HDR

I'd like to share some thoughts to the discussion of HDR. I'm very knowledgeable about HDR in the entertainment space but I have little to no understanding about the IT space. Nevertheless as I listened to the discussion during the Dec. '19 meeting some thoughts came to mind. I've corresponded a bit, and then chatted, with Pierre and he suggested I share my thoughts with the group.

Background
In the entertainment space, mixing of SDR and HDR content for presentation on a screen is not a major topic. It does come up re picture-in-picture (PIP) and overlay of graphics onto HDR where the (legacy) graphics generation may be been done in SDR. Typically the source device maps the SDR (gamma) into HDR (PQ or HLG) for interface to an HDR display.
For entertainment content the concept and use of a reference display and a reference viewing environment (dimly lit) is very important so that content produced is consistent. Use of a calibrated display in a similarly dim environment enables a viewer to see the image as intended. If the viewing environment differs (e.g. bright room) then the display should ideally compensate by altering the electro optical transfer function (EOTF) so that what is viewed and perceived is still (to the extent possible) faithful to what was produced.
Display of SDR (gamma) and PQ are defined to be display referred, i.e. the pixel value implies a specific luminance. This was not initially specified for SDR, as defined in Recommendations ITU-R BT.601 (SDTV) and BT.709 (HDTV), but was de-facto enforced by all displays being CRT and CRTs being effectively limited to about 100 nits luminance. Reference viewing rooms had been specified to use a background at 10% of the luminance of reference white on the display. When flat panels arrived they could go brighter and it became necessary for the ITU-R to formally specify the display transfer function (the gamma 2.4 EOTF) and the reference luminance (100 nits) which was done in BT.1886. BT.2035 specifed the HDTV SDR viewing environment to employ a 10 nit background (10% of 100 nit reference white) in BT.2035. HDR was documented in BT.2100. This document is comprehensive in that it clearly specifies reference OETF (capture), EOTF (display) and end-to-end (OOTF) transfer functions for both PQ and HLG. Also specified is a reference viewing environment (5 nits). A 16-bit floating point representation is also specified for both scene, or display luminance.
A reference SDR display is suitable for use by consumers in a darkish room. But typically TVs used in bright rooms display at 3x or so brightness, i.e. 300 nits. Computers also typically are used in bright rooms and display sRGB at several hundred nits. A computer+display used to view entertainment content in a critical viewing environment should be capable of matching the ITU specs. I personally prefer creation of images per the standards, and then altering the actual display based on the actual viewing environment. This alteration could be done in the computer rendering or in the display itself; I think doing this in the display is preferable.
HLG HDR display is a bit different from gamma SDR and PQ HDR. The reference display function (EOTF) is defined to simply map the full range of the signal to the luminance capability of the display; a 1000 nit display is a nominal reference for use in production. So a 500 nit HLG display will show a dimmer picture, and a 2000 nit HLG display a brighter picture. There is a gamma tweak in the EOTF that makes these variations in display luminance more acceptable. The simplicity in this is that no processing is needed to match an HLG image to a display.
The very high dynamic range of PQ (0-10k nits) can result in signals that can exceed the capabilities of any particular HDR display. What is done in a display is to accurately present the pixel luminance for pixels within the display's capabilities, and to limit (tone map or soft clip) those pixels representing highlights that exceed the display capability. So the take away should be that PQ displays accurately reproduce mid-tones (the 20 nit faces, and 200 nit diffuse whites) but crush highlights, and that HLG displays alter both mid-tones and highlights to map the full range of the signal to the full range of the display.

Thoughts for colorweb
A concept in my mind is that the computer equipment could support HDR by exploiting current standards and create an idealized image meant for display in the reference dim environment (as currently used for creation of entertainment content). This image would be provided to the display which would be charged with altering the delivered image to compensate for the display's own limitations (peak luminance, poor black rendition, limited color gamut, power limiting), the viewing environment, and user preference. Of course the processing needed to alter the ideal image to what the display should show could be done either in the display, in the computer, or split between them. I'm presuming use of RGB with primaries as defined in BT.2020/BT.2100. Those primaries cannot represent all visible colors, but as they are standardized for UHDTV, they are widely supported by displays as input signals (even though the displays can't actually display all the colors). If the display is ignorant of and unable to accept HDR, then an image that is created for HDR would have to be mapped down to SDR by the computer source device. HDR to SDR conversion is a big topic and there are no accepted standards or recommendations for it.
The image could be created in the BT.2100 16-bit floating point format where 1.0 indicates 1 nit on the display. Or the idealized image could be created directly in PQ (10k nit limit) or HLG (1k nit limit).  For a float image, the interface to the display could be 16-bit float, but I don't think there are currently standards to specify FP over DisplayPort or HDMI. Floats could be directly mapped to PQ or HLG which are supported by interfaces. For PQ interface, floating point values >10k would need to be pre-limited. For HLG interface, FP values >1k nits would need to be limited.
It would be straightforward to map SDR, PQ, or HLG onto a FP image. While SDR should ideally map to a 100 nit float value, there are industry practices to map SDR at 2x luminance to better match HDR brightness (this is documented in a MovieLabs recommendation and described in ITU-R Reports). So while PQ and HLG pixels could directly map to a FP value, SDR pixels could map directly, with a 2x (or other value) gain, or systems could employ sophisticated dynamic up-mapping algorithms (suitability of which might be content dependent, i.e. SDR graphics vs SDR video). For interface other than FP, another mapping of FP to either PQ or HLG would be needed, with clipping or soft-limiting in the case of high luminance pixels that exceed the capability of the interface format.
There can be latency introduced by the display needing to map the incoming HDR signal to match its own capabilities. Some entertainment/gaming source devices query a consumer display to determine the displays capabilities and then perform the display mapping inside the source device. Especially in gaming the reduction in latency is useful. So if the computer system understands the display capability the mapping could be done as the image to be delivered is generated, so instead of creating an idealized image an actual display image would be generated. This would simplify the display but complicate the image generation.
I plan to be on the call Monday night (PST time zone).
Craig Todd, Dolby Fellow




----------------------------

http://www.bbc.co.uk<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__www.bbc.co.uk%26d%3DDwMGaQ%26c%3DlI8Zb6TzM3d1tX4iEu7bpg%26r%3D_F90w7eDD4MBjtHx1p0KJg%26m%3DFfRd0Ub6Zefx0Dacx6hIv-AYDy8AbJxZLo81m22jF8Q%26s%3Dqyw6CfBQ2fVoX1lOwakmKTIps_wLwRlmNVfH7N6G2hw%26e%3D&data=04%7C01%7Cborg%40adobe.com%7C6b4b2be3e8404c902adc08d8b6bd7d2f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637460272258402645%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Sj4FDuaG%2FULDr9F%2FmXFlSJwPnIZTSEmce7St%2BcKWrD8%3D&reserved=0>
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------

________________________________
[Image removed by sender. FFEI Limited]<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ffei.co.uk%2F&data=04%7C01%7Cborg%40adobe.com%7C6b4b2be3e8404c902adc08d8b6bd7d2f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637460272258412639%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=OU9vYXFNMhxQ72oBS786%2BCdSs4%2BFI%2Fq1hLoYlab2hGA%3D&reserved=0>
CONFIDENTIALITY AND DISCLAIMER NOTICE

This message and any attachment is confidential and is protected by copyright. If you are not the intended recipient, please email the sender and delete this message and any attachment from your system.

Dissemination and or copying of this email is prohibited if you are not the intended recipient. We believe, but do not warrant, that this email and any attachments are virus free. You should take full responsibility for virus checking.

No responsibility is accepted by FFEI Ltd for personal emails or emails unconnected with FFEI Limited's business.

FFEI Limited is a limited company registered in England and Wales (Registered Number: 3244452).
[Image removed by sender. Join us on Linked In]<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fcompany%2Fffei&data=04%7C01%7Cborg%40adobe.com%7C6b4b2be3e8404c902adc08d8b6bd7d2f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637460272258412639%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=rckULDGeeYXSACnFuPm%2F6Yx9NWKvKbsoWuPbsdkoFwM%3D&reserved=0>[Image removed by sender. Follow @FFEI_ltd]<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FFFEI_ltd&data=04%7C01%7Cborg%40adobe.com%7C6b4b2be3e8404c902adc08d8b6bd7d2f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637460272258422633%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=R59S4x1kEW5tVbeqlcvH%2BwGGQTjw4hAMfeyu4ieSGhs%3D&reserved=0>[Image removed by sender. FFEI YouTube Channel]<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.youtube.com%2Fuser%2FFFEIPrintTechnology&data=04%7C01%7Cborg%40adobe.com%7C6b4b2be3e8404c902adc08d8b6bd7d2f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637460272258422633%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3mH1L29KWlL6bItwLphlbj9h7lXDwRp6b34T8jDcXvI%3D&reserved=0>
Registered Office: The Cube, Maylands Avenue, Hemel Hempstead, Hertfordshire, HP2 7DF, England.