Re: Wide Color Gamut and High Dynamic Range displays

On Wed, Jan 28, 2015 at 2:27 PM, Mark Watson <watsonm@netflix.com> wrote:
> I think so, yes. For example, in H.265 the "codec" is generally considered
> to be the part that takes in compressed video data and outputs three planes
> of pixels with 8 to 10 bits of data per pixel per plane.
>
> There is then "Visual Usability Information" (VUI) transmitted along with
> the compressed video signal which indicates how to interpret that output:
> color gamut, transfer function etc.

Okay, cool.  Yeah, I was using the term "codec" more widely, in a
probably incorrect way, to indicate all the metadata that's carried
along with the video.  Color profiles aren't really part of the image
format, and VUI isn't really part of the codec, but they both
format/profile and codec/VUI are part of the information that's used
to to process encoded data into display pixels.

> As a result, when querying codec capabilities (Profile, Level etc.) you tend
> to only get information about the capabilities of the first part, not the
> capability of the output device to interpret the raw output according to the
> SEI.
>
> It's not dissimilar from resolution in some respect: your device may support
> the necessary codec capabilities for 4K resolution but may not at that time
> be connected to a 4K-capable display.

Is there a way to query the hardware stack for VUI, like you can ask
monitors what their color profile is?

>> Anyway, I agree that you don't want to send wide-gamut stuff to
>> narrow-gamut screens if there's a properly-adjusted narrow-gamut
>> alternative you can offer (trusting the automatic correction algos
>> is... risky), and presumably the same applies to wide luminance.
>
> Yes, the mapping of High Dynamic Range content to Standard Dynamic Range is
> a creative process that is not easy to do well automatically.
>
> Also, there are existing devices which support codec capabilities (in the
> narrow sense described above - which is also the sense in which codec
> capability discovery works) suitable for HDR but which cannot interpret the
> output as HDR, even to map down to an SDR display.

Not quite sure what these words mean, but I don't think I have to -
point is, some devices might not even be capable of processing certain
types of better-quality video, and those that can will probably be
crappy at it, so we really want a way to deliver videos using those
better qualities only to devices that can handle them.

>> You'd know better than me - what kind of values are appropriate for
>> communicating this info?
>
> For color gamut, for video, the practically relevant choice is between
> BT.2020 and BT.709 (Content is created in other colorspaces, but generally
> mapped to one of these for delivery).
>
> However, for all I know there may be a whole different world of color spaces
> for graphics which the CSS group should consider.
>
> For HDR, the relevant information is the transfer function. H.265 lists
> quite a number of transfer functions for standard dynamic range, though I
> believe all the ones in current use can be classified as BT.709. For High
> Dynamic Range, presently on the table is SMPTE-2084, though in some contexts
> others are being discussed.

So what you're saying right now is that the appropriate way to talk
about these video qualities is by name?  I was hoping for something
more abstract and comprehensible, and hopefully arrangeable on a
continuum, but I'd understand if that's not really possible.

~TJ

Received on Wednesday, 28 January 2015 23:52:06 UTC