[RFC wayland-protocols] Color management protocol

[Graeme Gill]

Carsten Haitzler (The Rasterman) wrote:
> On Mon, 12 Dec 2016 17:57:08 +1100 Graeme Gill <graeme2 at argyllcms.com> said:

>> Right. So a protocol for querying the profile of each output for its surface
>> is a base requirement.
> 
> i totally disagree. the compositor should simply provide available colorspaces
> (and generally only provide those that hardware can do). what screen they apply
> to is unimportant.

Please read my earlier posts. No (sane) compositor can implement CMM
capabilities to a color critical applications requirements,
so color management without any participation of a compositor
is a core requirement.

> if the colorspace is native to that display or possible, the compositor will do
> NO CONVERSION of your pixel data and display directly (and instead convert sRGB
> data into that colorspace).

Relying on an artificial side effect (the so called "null color transform")
to implement the ability to directly control what is displayed, is a poor
approach, as I've explained at length previously.

> if your surface spans 2 screens the compositor may
> convert some to the colorspace of a monitor if it does not support that
> colorspace. choose the colorspace (as a client) that matches your data best.
> compositor will do a "best effort".

No compositor should be involved for core support. The application
should be able to render appropriately to each portion of the span.

> this way client doesnt need to know about outputs, which outputs it spans etc.
> and compositor will pick up the pieces. let me give some more complex examples:

That only works if the client doesn't care about color management very much -
i.e. it's not a color critical application. I'd hope that the intended use of
Wayland is wider in scope than that.

> compositor has a mirroring mode where it can mirror a window across multiple
> screens.

Sure, and in that case the user has a choice about which screen is
properly color managed. Nothing new there - the same currently
applies on X11, OS X, MSWin. Anyone doing color critical work
will not run in such modes, or will just use the color managed screen.

> some screens can or cannot do color management.

Nothing to do with screens - core color management is up to
the application, and all it needs is to know the display profile.

> what happens when the colorspace changes on the fly (you recalbrate
> the screen or output driving hardware). you expect applications to directly
> control this and have to respond to this and redraw content all the time?

Yep, same as any other sort of re-rendering event (i.e. exactly what happens with
current systems - nothing new here.)

> this can be far simpler:
> 
> 1. list of supported colorspaces (bonus points if flags say if its able to be
> native or is emulated).
> 2. colorspace attached to buffer by client.
> 
> that's it.

If you don't care so much about color, yes. i.e. this is
what I call "Enhanced" color management, rather than core.
It doesn't have to be as flexible or as accurate, but it has
the benefit of being easy to use for applications that don't care
as much, or currently aren't color managed at all.

Graeme Gill.