HDR support in Wayland/Weston

[Chris Murphy]

On Mon, Mar 4, 2019 at 1:32 AM Simon Ser <contact at emersion.fr> wrote:
>
> 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.

Another interesting use case, Flatpaks. Say I have a flatpak
application which depends on KDE, so I have org.kde.Platform runtime
installed, how does an application that wants to alter display white
point work in such a case? It'll presumably go through the KDE runtime
to try to do this, but then how does that get communicated when this
is actually running on GNOME? And then how does it properly get reset
once that application quits?

I don't really need a literal explanation. I'm fine with simplistic
trust based explanations.

> Is there a "good way" to combine multiple LUTs?

Whether 1D, 2D, 3D LUTs, they can be concatenated yes. I'll let Graeme
answer the math aspect of it, he probably knows it off the top of his
head. I don't. But yes it's possible, and yes it's really easy to do
it wrong in particular when there are white point differences. But
likely also more complicated in an HDR context. So yeah you'll
probably want an API for it.

Another use case for this would be simulating different standard
observers, including dichromacy and anomalous trichromacy (of which
there are several each but only a couple are particularly common).
When designing user interfaces, or signage, or advertising, it's a
really good idea to check if some substantial number of users are
going to get hit with confusion because they can't distinguish
elements in a design. This is normally implemented in the application
rather than in the OS, but macOS does have an option for this.

And now that I think of it, I'm not sure they're even using 'space'
class ICC profiles but rather 'abstract' class. You can think of the
'abstract' class as an analog to 'device link' where the device link
is implies a direct deviceA>deviceB, or even direct deviceA>deviceC
(the A>B>C concatenation is precomputed when the device link is
built), the abstract profile works in non-device color spaces such as
L*a*b* or XYZ, you can think of them as a kind of effects filter.

And for that matter, the "blue light filter" can be described with an
abstract profile, or even two of them to define the endpoints of a
continuum with something like a slider that effectively concatenates
them with a varible coefficient to weight them however the user wants,
with like a slider or something.

These things don't necessarily need to be literal ICC profiles as a
file on disk if you don't want. The non-LUT display class (primaries
plus tone curve which can be defined as a gamma function or even
parametrically), space class, and abstract class are typically pretty
tiny, they could be created on the fly and fed into lcms2 as virtual
profiles, and let it handle all the transforms with its well tested
math. Named color class, device link class, output class, input class,
can be quite a bit larger, and even massive in some cases - but off
hand I don't see a use case for them here.

-- 
Chris Murphy