[PATCH] unstable: add HDR Mastering Meta-data Protocol

[Graeme Gill]

Pekka Paalanen wrote:

> The only question is, do color management and HDR support conceptually
> make sense as independent features, or would implementations always
> support both with essentially the same effort?

In my view, you can certainly add an HDR extension independently
of a color management extension, but it would either be a hack
to get things working (i.e. make all sorts of general display colorspace
assumptions or approximations) or if less hacky, would start to encompass
general color management concerns. A Color Management extension on the
other hand adds a bunch of non-HDR related stuff, but HDR then slots in as
a sub-case of handling differences in display characteristics.

> "Supporting HDR" here means only that the compositor is able to process
> HDR content from clients, it does not include the capability to drive
> HDR monitors. IOW, a compositor that only converts HDR content to SDR
> is a valid HDR implementation from protocol perspective. It merely
> advertises all outputs as SDR.

True, but once you allow for a display to be labelled HDR and
have an associated color profile, there isn't that much to handling HDR
like any other display.

> The big question here is: does a HDR video, with reasonable defaults if
> not explicitly defined, allow to programmatically manufacture a custom
> ICC profile with the HDR primaries?

Yes, this works. Some HDR TV calibration already takes this approach.

> What I mean is, if a compositor implements color management, is there
> any good reason to not implement HDR luminance mapping as well? At
> least the implementation would not differ, just the parameters or
> tables. That is why I suspect supporting HDR will be easy on top of a
> good color conversion implementation.

I agree.

> Harish Krupo <harish.krupo.kps at intel.com> wrote:

>> Out-of-gamut pixels are handled completely separately compared to
>> out-of-dynamic-range pixels. Out of gamut can be solved either clamping
>> the color after conversion or by using a nearest approximation of the
>> color available within the colorspace.
>> Out-of-dynamic-range OTOH, requires applying tone mapping to adjust the
>> luminance ranges.

Adapting the luminance range is just another aspect of mapping
one color space to another. One mechanism for achieving this is
to use a relative colorspace description of the spaces and then
use an orthogonal luminance mapping (such as tone mapping for HDR -> SDR).

> I thought that some of the rendering intents of color management do the
> same as HDR luminance mapping. Do they not? Only few parameters more to
> adjust the ranges of the mapping curves.

Standard ICC intents generally do not, because most of them work
around a Relative Colorimetric assumption. Absolute Colorimetric
in theory could support this, but in practice is not a mechanism
that would work the way you want for HDR handling (i.e.
it would work for SDR->HDR, but would clip HDR->SDR, and
would have the side effect of not aligning the white points,
which you probably don't want it to do.)

But I think it should be relatively straight forward to
augment the standard ICC CMM linking parameters with some
HDR options. (In terms of implementation I would hope
that lcms's plugin architecture would help facilitate this,
or at worst it could be patches and the changes fed back
upstream to Marti). The two options I would imagine
adding would be SDR->HDR brightness (i.e. what the
SDR white brightness should be), and for HDR->SDR what
the HDR diffuse white is and possibly a tone mapping
strategy. (The technical details of this can be guided
by something like the ITU-R BT.2390-2 EETF).

> It is also likely that color management will need a wl_output extension
> object of its own, so if HDR information can be integrated in that, it
> would be simpler to use.

Yep.

> There is no need to ensure at the protocol level. If the compositor
> advertises HDR support and there exists at least one HDR output, the
> player should always produce HDR frames if possible, especially if it
> is cheaper for the player than SDR. The compositor will take care of the
> SDR conversion if necessary, and there won't be glitches if the window
> moves between HDR and SDR monitors as there is no need for the client
> to catch up.

In a color managed implementation, the player just need mark the
source with the video ICC profile and HDR intent information for
default handling by the Compositor. If it wanted to do
the HDR handling itself, it would download the output ICC profile
to figure out its conversion from video source to output space,
and then mark the buffer as being in the primary output colorspace
so that the Compositor knows it doesn't have to do anything.

Cheers,
	Graeme Gill.