[RFC wayland-protocols] Color management protocol

[Graeme Gill]

Carsten Haitzler (The Rasterman) wrote:
> On Fri, 9 Dec 2016 15:30:40 +1100 Graeme Gill <graeme2 at argyllcms.com> said:

>> I thought I'd explained this in the previous post ? - perhaps
>> I'm simply not understanding where you are coming from on this.
> 
> you didn't explain before if the point is for this to be mandatory or optional.

I'm not sure exactly what you mean by "this".

I've suggested two color management extensions, one building on
the other. By being an extension, I assume that neither one is
mandatory, although "core" would be a dependence of "enhanced".

> above you basically say it has to be mandatory as applications will then fail
> to run (at least some set of them might).

That's not at all what I said. I said that applications have the
option of falling back to more basic approaches :-
enhance back to core, core back to none.

> when you add extra features like new colorspace support, people writing apps
> and toolkits nee to know what the expectation is. can they just assume it will
> work, or do they need to have a fallback path on their side.

I've not mentioned any new colorspace support, so I'm not
sure what you are talking about.

> compositor writers need to know too. if color management is mandatory then
> their compositor is basically broken until they add it.

Naturally a compositor that supports an extension, would
would have to implement it!

> i don't see a difference between enhanced and core.

Hmm. They are quite distinct.

 core: The application either implements its own CMM (lcms or
  ArgyllCMS icclib/imdi etc.), or uses a system provided CMM
  (i.e. ColorSync, WCS, AdobeCMM etc.).

 enchanced: The compositor implements some level of CMM itself,
  using one of the above libraries, GPU etc.

 core: The application requires information from the graphics
  system (via Wayland in this particular discussion), namely
  the profile for the display corresponding to each
  pixel region.

 enhanced: The compositor is provided with source colorspace
  profiles by the application.

 core: The application uses its CMM to transform source colorspaces
  to the display colorspaces, and sends the pixels to the graphics system.

 enhanced: The compositor uses its CMM to transform the pixels provided
  by the application in the provided source colorspaces to the display
  colorspaces.

> color management means:
> 
> 1. being able to report what colorspace is "default" on the display right now
> (and what may be able to be enabled possible at request).

I'm not sure what you mean by "enabled". A display colorspaces is just information
that is needed by the CMM, so it is either known and available to what needs
it, or not known or not available to what needs it.

> 2. being able to report what colorspaces are supported at all (either natively
> by the display or by emulation)

Not needed for core color management - all that is required is
to be able to send pixels in the native display space to the display.

> 3. the ability for a client to define a specific colorspace for a buffer. (the
> choice of the colorspace of the display itself should be left to the
> compositor).

Not needed for core color management - the application deals
with source color spaces internally.

To reiterate:

1) Core color management support is essential because you can't assume that
  a CMM implemented in the compostor has all the capabilities that every
  application requires - particularly if it is a color critical application.

2) Core color management support is essential to allow color management applications
  such as color profilers work. Without color profilers, there are no accurate
  color profiles for your display, and color critical applications won't be viable.

If you want Wayland to be on parity with existing systems (MSWin, OS X, X11),
then you need core color management support.

> the only difference is the set of colorspaces wanted by client and by supported
> by compositor. core and enhanced are arbitrary labels.

No. See above.

> what matters is a
> common colorspace. right now in wayland it's all sRGB so everyone agrees (i'm
> ignoring yuv etc. buffer formats. just talking RGB ones).

That's not how CMM's work. The common color space is the profile connection
space, which is based on CIE XYZ.

> so the questions are:
> 
>   * if all of these above are missing: what happens?
>   * if the list of colorspaces natively supported by the screen does not have a
> common set of colorspaces the client wants: what happens?
>   * if the list of all colorspaces (native or emulated) by the compositor does
> not have a common set with the client: what happens?

Only questions for enhanced color management, and since this isn't
required by color critical applications, a relaxed level of support
is likely to be useful.

> what i want to know if how mandatory will this be, as most users will never
> have a scenario where their display can do more than "dumb" sRGB and any
> compositor claiming to support colorspaces will have to convert down to sRGB
> anyway, and if clients start exiting because the compositor is being honest and
> saying that that colorspace cant be supported, then this will eventually lead
> to compositors lying and claiming all these colorspaces work/are native to stop
> apps exiting, and so now all you do is add overhead to work around client apps
> that are just behaving badly.

These sorts of issues only arise if your be-all and end-all of color management
is doing it in the compositor, and for the reasons I state above, I don't
think this is satisfactory.

If color management is an extension, I don't see how any of it can be mandatory.

Naturally in a color managed situation there are a variety of options for
providing fall back display color profiles - for instance: display type generic,
EDID derived profiles, or worst case assume sRGB.

Graeme Gill.