HDR support in Wayland/Weston

[Graeme Gill]

Simon Ser wrote:
> On Monday, March 4, 2019 8:13 AM, Graeme Gill <graeme2 at argyllcms.com> wrote:

>> 2) Implement virtual per channel LUTs, with the compositor combining them
>>    together in some way, and have some means of the color management applications
>>    being aware when the display is being interfered with by another application,
>>    so that the user can be warned that the color management state is invalid.
> 
> Is there a "good way" to combine multiple LUTs?

It might be possible to compute aproximately color correct
device value curves that can be combined together, based
on the ICC profile characterization. The advantage
of this is that it could be applied to a display
without any application having to be aware of it
(although a color critical application may want to
be able to warn the user.)

>> 1) A color managed API that lets an application shift the display white point
>>    using chromatic adaptation, so that such blue light filter applications
>>    can operate more predictably, as well as some means of the color management
>>    applications being aware of when this is happening.
> 
> How should this look like? Disclaimer: I have no idea how these applications
> work and I know nothing about color management.

The logical way of supporting this in ICC profile terms would be
to allow for the insertion of an ICC Abstract Profile in
the color conversions (This is a PCS -> PCS transform. So
you would do a Source Dev->PCS, Abstract PCS->PCS, Destination PCS->Dev).
A chromatically correct white point shift would be pretty
simple to specify as an abstract profile.

Conversions done by the Compositor could incorporate the abstract
profile in the linking. Conversions done by color aware applications
could not be forced to honor the abstract profile, but they could choose
to honor it, and they would explicitly be aware of the color
modification although not the reason/intent of it without
some extra meta information.

> I'm guessing this is a restriction of the "change the whole LUTs" API. Are there
> any features the "blue light filter" app won't be able to implement when
> switching to this API?

Good question. I'm not aware of the range of applications that do this
kind of thing. I guess a search of open source apps that use the
relevant API's might give a clue.

> Would the compositor part become complicated (judging
> from [2] it seems different "blue light filter" apps may compute LUTs
> differently)?

A little, it shouldn't add much since lcms supports Abstract profiles.

Cheers,
	Graeme Gill.