Re: Wide Color Gamut and High Dynamic Range displays

On Wed, Jan 28, 2015 at 1:30 PM, Rik Cabanier <cabanier@gmail.com> wrote:
> On Wed, Jan 28, 2015 at 1:13 PM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>> On Wed, Jan 28, 2015 at 12:26 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>> > On Wed, Jan 28, 2015 at 9:02 AM, Mark Watson <watsonm@netflix.com>
>> > wrote:
>> >> It would be nice to be able to detect whether the display has the
>> >> capability of rendering Wide Color Gamut and High Dynamic Range video.
>> >>
>> >> This is independent of codec support: in fact the video codec itself
>> >> may
>> >> be unaware of the colorspace and dynamic range of the encoded video. It
>> >> may
>> >> also be the case that the media pipeline in a device supports these
>> >> things
>> >> but the presently connected display does not.
>> >>
>> >> For WGC, the basic question is whether the display can interpret data
>> >> coded in the BT.2020 or DCI P3 colorspaces (I say "interpret"
>> >> deliberately,
>> >> because I'm unaware of any displays that can render the full BT.2020
>> >> space
>> >> yet.)
>> >>
>> >> Would it make sense to add attributes for these properties to the CSS
>> >> OM
>> >> View Module ? Other suggestions ? Questions ?
>> >
>> > What are you planning on doing with that information?
>> > AFAIK it is defined that pages are composited in sRGB and then mapped to
>> > the
>> > monitor profile.
>>
>> sRGB supports wide gamuts (at least theoretically). It's just outside
>> the standard gamut, but still representable.
>
> Is there any browser that supports this and uses those values?
> This is also not compatible with the BT.2020 or DCI P3 colorspaces that
> Mark's requesting.

Browsers *do* handle wide-gamut images, when they're appropriately
tagged and going straight to the screen.  And we (Chrome) are working
on making it composite properly, too, though that's difficult.

>> > Would you use this to change color handling of a full-screen video?
>>
>> You can send different sources to <video> based on a media query.
>
> Since a video element is composited just like other elements, I don't see
> how that would make a difference.
> Pushing wide gamut pixels into an sRGB back buffer would just make the video
> darker. (unless you map then to sRGB in which case there was no need for the
> wide gamut video stream)

We'd be in the same situation as wide-gamut images - if they go
straight to the screen, we can send the better info; if they're
composited, they get smushed into the sRGB gamut first, until we solve
the technical challenges and can composite in a wider space.

~TJ

Received on Wednesday, 28 January 2015 23:43:12 UTC