HDR support in Wayland/Weston

[Pekka Paalanen]

On Fri, 11 Jan 2019 18:25:01 +1100
Graeme Gill <graeme2 at argyllcms.com> wrote:

> Sharma, Shashank wrote:
> 
> Hi,
> 
> While I'm sure you could hard code various color space assumptions into
> such an implementation (and perhaps this is a pretty reasonable way
> of doing a proof of concept), it's not a good long term solution,
> and could end up being something of a millstone. What's missing
> is any serous Color Management in Wayland. It's a bigger project
> to fix that, but HDR would then be able to slot into a much more usable
> framework.

Hi,

that I agree with. At least the final design should aim to integrate
with color management related public application protocol extensions.

In other words, I think it would be ok to use place-holder extensions
if the color management extensions are not there yet, but plan for
swapping to the proper extension later when you aim for the larger
public.

In practise, that would mean more than one Wayland global interface for
HDR purposes, so that those that deal with color spaces can later be
dropped in favour of the color extensions instead of stabilized.

> > - HDR content/buffers are composed in REC2020 colorspace, with bit depth 10/12/16 BPC.
> > Some of the popular formats are P010,P012,P016.  
> 
> While REC2020 based HDR colorspaces are very popular, they aren't the only ones out there.
> 
> > - Normal SRGB buffers are composed in SRGB color space following REC709 specifications.  
> 
> As far as I'm aware (I haven't been closely monitoring this mailing
> list since the last rather long and unsatisfactory discussion about color
> management), Wayland works in display dependent colorspace, since there
> is no facility for it to know how to convert from anything else to the
> display space (i.e. no knowledge of display profiles so it doesn't
> know what sRGB is). In all other computer graphic display systems, it's
> up to the client to be informed about each display colorspace is, and
> to do color conversion to the display space either itself, or by using
> operating system libraries. The operating system provides the display
> profile information to allow this. As far as I was informed, Wayland
> is architected in such a way that this is not possible, since clients
> have no knowledge of which display the pixels they send will end up on.

Nothing has changed there.

> Also note that while the use of an intermediate compositing space is
> essential when combining different colorspace sources together, it's
> not desirable in other situations where maximum fidelity and
> gamut are desired i.e. Photography. (The double conversions are a
> possible accuracy loss, and it makes it very difficult to
> achieve good gamut mapping from large gamut sources.)

Right, ideally a series of conversions that should amount to identity
would be completely skipped on a frame by frame basis. Thankfully that
will be a compositor internal implementation detail - there should be
no protocol that demands unnecessary work.

> > - For accurate blending in display engines, we need to make sure following:
> >     - All the buffers are in same colorspace (Rec 709 or Rec 2020)
> >     - All the buffers are liner (gamma/EOTF removed)
> >     - All the buffers are tone mapped in same zone (HDR or SDR)  
> 
> Is that something that Wayland should really know about though ?
> i.e. shouldn't that be an application issue, where Wayland provides
> the necessary mechanisms to achieve correct composition ?
> (Or in fact is that what you are suggesting ?)

Wayland and apps need to provide the compositor all the necessary
information for the compositor to do all the conversions, mapping and
blending correctly, if it has to.

This is because an application will provide only one image for a
wl_surface, and the compositor may show that on any number of any kind
of outputs at once. The alternative would be for apps to provide one
image per each output for one wl_surface, so that the compositor can
pick the correctly rendered one - except that would still not allow the
compositor to blend correctly, it would only work for opaque windows.
It would also prohibit the use of display hardware to off-load any part
of the image processing.

But, just like HiDPI, it is not only the apps telling the compositor
what kind of image they are providing (wl_surface.set_buffer_scale
request). The compositor describes the outputs (wl_output.scale event)
so that applications can choose the best way to render, and maybe save
some work in the compositor at the same time.

Nothing prevents adding more protocol to give apps more hints to behave
more optimally wrt. to the compositor's internal pipeline.

> >     - Now, in order to re-apply the HDR curve, compositor will apply CRTC level gamma, so
> > that the output buffer is non-linear again.  
> 
> Note that in most Color Managed systems, the CRTC per channel lookup curves are used for
> the purposes of display calibration, although Wayland doesn't currently support
> Color Management tools at all (unlike X11 or other operating systems, it provides no
> access to the CRTC by client software).

Correct, and Shashank is not proposing anything different. The
per-channel lookup curves are a compositor internal detail, always
programmed by the compositor correctly according to what it happens to
be showing each monitor refresh on that specific monitor.

> Perhaps it's worth re-visiting some of the ideas about how to add Color Management
> to Wayland, to see how HDR could fit into it ?

Yes, indeed.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190114/3341c8c1/attachment.sig>