HDR support in Wayland/Weston

[Kai-Uwe]

Am 04.03.19 um 09:32 schrieb Simon Ser:
> On Monday, March 4, 2019 8:13 AM, Graeme Gill <graeme2 at argyllcms.com> wrote:
>> And the current favorite is "blue light filter" effects, for which numerous
>> applications are currently available. They tweak the white point
>> of the display by arbitrarily modifying the hardware per channel LUTs.
>> (i.e. f.lux, Redshift, SunsetScreen, Iris, Night Shift, Twilight etc.)
>>
>> Such applications have their place for those who like the effect, but
>> ideally such usage would not simply blow color management away.
> FWIW wlroots has a protocol for this [1]. GNOME and KDE have this feature
> directly integrated in their compositor.

These tools work in a assumption of all device RGB is the same (sRGB).
That is, mildly written, not ideal.

The shortcomings of ignoring the output color space becomes evident,
when one does multi monitor white point adjustment. A BT2020 and a
REC709 or DCI3 display will simply widely disagree on red light
modification with manipulating the 1D LUT without considering the device
specifics. The correct way is:

* convert R+G+B ramps to CIE*XYZ (usually by a ICC profile)
* do chromatic adaption in CIE*XYZ, monitor white point -> common
destination white point (D50, K2800...)
* convert back to per output device RGB [CIE*XYZ->deviceRGB]
* merge with ICC profile VCGT calibration ramp, and finally
* apply the 1D LUT for the correct output

All the above tools do not take care of the output profile and apply to
all outputs the same device unspecific manipulation assuming sRGB.
(Assuming sRGB as device primaries performs pretty bad in face of BT2020
/ HDR.)

>> In order of desirability it would be nice to:
>>
>> 3) Have the hardware Luts restored after an application that uses them
>>    exits (i.e. like OS X handles it).
> Agreed. This is done in our protocol and there's no such issue when builtin in
> the compositor.
>
>> 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?

You mean 1D LUT, yes in CIE*XYZ or a other liner blending space. See above.

>> 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.
>
> 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? Would the compositor part become complicated (judging
> from [2] it seems different "blue light filter" apps may compute LUTs
> differently)?

White point adaption is singe very long time part of the ICC spec.

> Since many compositors (GNOME, KDE, wlroots, maybe more) implement a way to
> apply a "blue light filter", I think it's important to be able to notify color
> management applications that they don't have exclusive access. Or maybe this
> should just be handled internally by the compositor? (Display a warning or
> something?)
A color management front end can take care of such things, but only if
it can know, that a manipulation is in action. Be that manipulation
visual impairment simulation, white point altering, saturation altering,
sepia effect, you name it ....
> [1]: https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-gamma-control-unstable-v1.xml
> [2]: https://github.com/jonls/redshift/blob/master/README-colorramp

Both links do not talk about device specific LUT manipulation. They are
color management unaware and the outcome will vary from device to device.

That said, blue light reduction is a desirable feature. I enjoy it each
day/night using ICC style color management.

Kai-Uwe Behrmann
-- 
www.oyranos.org