- From: Simon Thompson-NM <Simon.Thompson2@bbc.co.uk>
- Date: Tue, 16 Mar 2021 15:03:23 +0000
- To: "Seeger, Chris (NBCUniversal)" <Chris.Seeger@nbcuni.com>, Jim Helman <jhelman@movielabs.com>, Lars Borg <borg@a1830.dscd.akamai.net>, Christopher Cameron <ccameron@google.com>, "public-colorweb@w3.org" <public-colorweb@w3.org>, Pierre-Anthony Lemieux <pal@sandflow.com>
- Message-ID: <AM6PR01MB620006103664CEF23AB5C99EFD6B9@AM6PR01MB6200.eurprd01.prod.exchangelabs>
Hi Two of the three solutions in the document under discussion are scene-referred: 1. ITU-R BT.2100 scene-referred linear floating point signal (Table 10) and 2. ITU-R BT.2100 hybrid log-gamma (Table 5) The definitions of compositing levels for these two systems are based on %age signal level of these scene-referred signals and not the luminance output of an unknown display that the system is connected to. If we're going to exclude scene-referred video systems then that will also exclude ITU-R BT.709, which is most definitely scene-referred. Even the reference EOTF for SDR TV, specified 21 years later in ITU-R BT.1886, does not specify a nominal peak luminance (Lw) for the display. It is often thought that BT.1886 specifies a nominal peak luminance of 100 cd/m^2 for an SDR display, however, this is only in an informative annex as an example that could be used to emulate a CRT display. For television reference monitors, the EBU specified a range of luminances dependent on usage and viewing environment. SDR TV is therefore clearly a scene-referred system. Furthermore, even though the sRGB specification mentions 80cd/m^2, most modern computers do not use this nominal peak luminance as it's too dim for most viewing environments. Best Regards Simon -- Simon Thompson MEng CEng MIET Senior R&D Engineer BBC Research and Development South Laboratory ________________________________ From: Seeger, Chris (NBCUniversal) <Chris.Seeger@nbcuni.com> Sent: Tuesday, March 16, 2021 13:21 To: Jim Helman <jhelman@movielabs.com>; Lars Borg <borg@a1830.dscd.akamai.net>; Christopher Cameron <ccameron@google.com>; public-colorweb@w3.org <public-colorweb@w3.org>; Pierre-Anthony Lemieux <pal@sandflow.com> Subject: Re: [EXTERNAL] Re: Proposal for HTMLCanvasElement HDR compositing modes We agree. Please stay in Display-Light. From: Jim Helman <jhelman@movielabs.com> Date: Monday, March 15, 2021 at 11:54 PM To: Lars Borg <borg@a1830.dscd.akamai.net>, Christopher Cameron <ccameron@google.com>, public-colorweb@w3.org <public-colorweb@w3.org>, Pierre-Anthony Lemieux <pal@sandflow.com> Subject: [EXTERNAL] Re: Proposal for HTMLCanvasElement HDR compositing modes Hi, I agree. Scene light has a very specific definition in the context of capture and in the color grading/correction world. In our context here, we should avoid getting into mappings from scene-referred to display-referred systems, which are usually highly subjective and depend on the desired creative "look." - Jim On 3/15/21 8:26 PM, Lars Borg wrote: Chris C, One concern I have is the term scene light. If this means scene-referred, then that’s a problem as sRGB is defined only for display light, not for scene light. So then additional conversions would be needed to convert sRGB to canvas. And if scene light doesn’t mean scene-referred then what does it mean? It causes confusion. Please find a way to stay in display-referred color space. Lars From: Christopher Cameron <ccameron@google.com><mailto:ccameron@google.com> Date: Sunday, March 14, 2021 at 8:30 PM To: "public-colorweb@w3.org"<mailto:public-colorweb@w3.org> <public-colorweb@w3.org><mailto:public-colorweb@w3.org>, Pierre Lemieux <pal@sandflow.com><mailto:pal@sandflow.com> Subject: Re: Proposal for HTMLCanvasElement HDR compositing modes Resent-From: <public-colorweb@w3.org><mailto:public-colorweb@w3.org> Resent-Date: Sunday, March 14, 2021 at 8:29 PM FYI, I have updated the PR to rely more heavily on standard broadcast terminology, and included a (hopefully-clarifying) definitions section at the top. On Wed, Mar 10, 2021 at 2:42 PM Christopher Cameron <ccameron@google.com<mailto:ccameron@google.com>> wrote: I put up a PR with a writeup of what I think is the best scheme for HDR compositing of HTMLCanvasElements, given our various constraints. Please review and/or comment for our next meeting on March 16! https://github.com/w3c/ColorWeb-CG/pull/15<https://urldefense.com/v3/__https:/nam04.safelinks.protection.outlook.com/?url=https*3A*2F*2Fgithub.com*2Fw3c*2FColorWeb-CG*2Fpull*2F15&data=04*7C01*7Cborg*40adobe.com*7Cf4f9872e7f6a408760f808d8e77bbfcf*7Cfa7b1b5a7b34438794aed2c178decee1*7C0*7C0*7C637513866045481738*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=vAN*2BA6ZzmQ4r*2F3m7SlyZVOU4s8nn5nu50rjT0S2XpfU*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!PIZeeW5wscynRQ!6mlLIp7Z_m5FoUU-qfpGA4Tn3i4RMsTXJuy0E55neWP9Vv8L36ITozr3pAZp6rofTA$> -- Jim Helman | MovieLabs | o: +1.650.646.2277 m: +1.650.576.1755 | jhelman@movielabs.com<mailto:jhelman@movielabs.com> | 222 Kearney St, Suite 300, San Francisco, CA 94108
Received on Tuesday, 16 March 2021 15:11:00 UTC