Re: Thoughts on HDR

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>
> *Date: *Monday, January 11, 2021 at 9:04 AM
> *To: *Simon Thompson <Simon.Thompson2@bbc.co.uk>, 
> "public-colorweb@w3.org" <public-colorweb@w3.org>
> *Cc: *Imane Mnie Filali <imane.mniefilali@bbc.co.uk>
> *Subject: *RE: Thoughts on HDR
> *Resent-From: *<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>
> *Sent:* Monday, January 11, 2021 8:44 AM
> *To:* Todd, Craig <CT@dolby.com>; public-colorweb@w3.org
> *Cc:* Imane Mnie Filali <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/m^2 , HLG is not limited to 1000 cd/m^2 and has been tested up to 
> 4000+ cd/m^2 .
>
> 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/m^2 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%7Cf671a527fcd241fce7d708d8b663bac6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637459886757804880%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=BKF7nqb7hFpRnTSQDFOj%2FSAD9KY3zzKSjaDj0%2Fq0WmM%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.
>
> ---------------------
>