[RFC wayland-protocols] Color management protocol

[Daniel Stone]

Hi Chris,

On 20 December 2016 at 18:11, Chris Murphy <lists at colorremedies.com> wrote:
> On Tue, Dec 20, 2016 at 10:02 AM, Daniel Stone <daniel at fooishbar.org> wrote:
>> On 17 December 2016 at 10:16, Graeme Gill <graeme2 at argyllcms.com> wrote:
>>> As I've explained a few times, and extension is needed to provide
>>> the Output region information for each surface, as well as each
>>> outputs color profile, as well as be able to set each Outputs
>>> per channel VideoLUT tables for calibration.
>>
>> That's one way of looking at it, yes. But no, the exact thing you're
>> describing will never occur for any reason. If you'd like to take a
>> step back and explain your reasoning, as well as the alternate
>> solutions you've discarded, then that's fine, but otherwise, with a
>> firm and resolute 'no, never' to this point, we're at a dead end.
>
> We can't have multiple white points on the display at the same time;
> it causes incomplete user adaptation and breaks color matching
> everywhere in the workflow. The traditional way to make sure there is
> only one white point for all programs is manipulating the video card
> LUTs. It's probably not the only way to do it. But if it's definitely
> not possible (for reasons I'm not really following) for a privileged
> display calibration program to inject LUT data, and restore it at boot
> up time as well as wake from sleep, then another way to make certain
> there's normalized color rendering on the display is necessary.

Right: 'ensure whitepoint consistency' is an entirely worthwhile goal,
and I think everyone agrees on the point. 'Give clients absolute
control over display hardware LUT + CTM' is one way of achieving that
goal, but not a first-order goal in itself.

The reason applications can't drive the LUT is because, as you say,
there's not always just one. If there were only one application, then
why not just write directly to KMS? There's little call for a window
system in that case.

> The holy grail is as Richard Hughes describes, late binding color
> transforms. In effect every pixel that will go to a display is going
> to be transformed. Every button, every bit of white text, for every
> application. There is no such thing as opt in color management, the
> dumbest program in the world will have its pixels intercepted and
> transformed to make sure it does not really produce 255,255,255
> (deviceRGB) white on the user display.

I agree that there's 'no such thing as an opt in', and equally that
there's no such thing as an opt out. Something is always going to do
something to your content, and if it's not aware of what it's doing,
that something is going to be destructive. For that reason, I'm deeply
skeptical that the option is routing around the core infrastructure.

As arguments to support his solution, Graeme presents a number of
cases such as complete perfect colour accuracy whilst dragging
surfaces between multiple displays, and others which are deeply
understandable coming from X11. The two systems are so vastly
different in their rendering and display pipelines that, whilst the
problems he raises are valid and worth solving, I think he is missing
an endless long tail of problems with his decreed solution caused by
the difference in processing pipelines.

Put briefly, I don't believe it's possible to design a system which
makes these guarantees, without the compositor being intimately aware
of the detail.

This doesn't mean that every input pixel must be sRGB and the
compositor / GPU / display hardware must transform every pixel, but
that the compositor needs to be, at a minimum, aware. Again, I think
everyone agrees that the perfect case for deeply colour-aware
applications, is that they present content in such a way that, in the
ideal steady state, it can be presented directly to the display with a
NULL transform.

> The consequences for a single dumb program, for even 2 seconds,
> showing up on screen with 255,255,255 white on an uncalibrated display
> is the user's white point adaptation is clobbered for at least 10
> minutes, possibly 30 or more minutes. And it doesn't just affect the
> other things they're viewing on the display, it will impact their
> ability to reliably evaluate printed materials in the same
> environment.
>
> So the traditional way of making absolutely certain no program can
> hose the workflow is this crude lever in the video card. If you can
> come up with an equivalently sure fire reliable s that doesn't demand
> that the user draw up a list of "don't ever run these programs" while
> doing color critical work, then great. Otherwise, there's going to
> need to be a way to access the crude calibration lever in the video
> card. Even though crude, this use case is exactly what it's designed
> for.

It isn't a panacea though. It is one way to attack things, but if your
foundational principle is that the display hardware LUT/CTM never be
out of sync with content presented to the display, then my view is
that the best way to solve this is by having the LUT/CTM be driven by
the thing which controls presentation to the display. Meaning, the
application is written directly to KMS and is responsible for both, or
the application provides enough information to the compositor to allow
it to do the same thing in an ideal application-centric steady state,
but also cope with other scenarios. Say, if your app crashes and you
show the desktop, or you accidentally press Alt-Tab, or you get a
desktop notification, or your screensaver kicks in, or, or, or ...

It seems to me like Niels's strawman was a reasonable foundation on
which you could build a protocol which allowed this. Namely, in the
ideal steady state, the app would have _effective_ control of the
LUTs/CTM. But being mediated by a colour-aware compositor, the
compositor would also be able to deal with states other than the
application's perfect state, without destroying the user's whitepoint
adaptation. It's difficult, but I think also a worthwhile goal.

tl;dr we agree on goal but not implementation detail

Cheers,
Daniel