Re: Wide Color Gamut and High Dynamic Range displays

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.


> > 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)