[RFC wayland-protocols] Color management protocol

[Graeme Gill]

Carsten Haitzler (The Rasterman) wrote:
> On Tue, 13 Dec 2016 17:14:21 +1100 Graeme Gill <graeme2 at argyllcms.com> said:

> this == support for color correction protocol AND actually the support for
> providing the real colorspace of the monitor, providing non SRGB pixel data by
> clients in another colorspace (eg adobe) and it MUST work or apps will
> literally fall over.

That's not a scheme I'm recommending.

> at the end of the day there will be some extension and then some form of
> guidance to developers. e.g. you can guarantee this will work, or "this may or
> may not work. deal with it".

Sure.

> well there are extensions that are managed outside of wayland as a project.
> these obviously are not mandatory. the more core it becomes the more it is
> likely "mandatory".

Sure.

> not a format. a colorspce. R numbers are still R, as are G and B. it's just
> that they point to different "real life spectrum" colors and so they need to be
> transformed from one colorspace (sRGB to adobe RGB or adobe to sRGB).

My point stands. I've not mentioned new colorspaces.

> i really do not think this is needed. simply a list of available colorspaces
> would be sufficient. application then provide data in the colorspace of it's
> choice given what is supported by the compositor and the input data it has...

And I think it is core, for all the reasons I've listed.

>>  enhanced: The compositor is provided with source colorspace
>>   profiles by the application.
> 
> i again don't see why this is needed.

Hmm. How else does the compositor know how to transform from
the given colorspace to the display colorspace ?

> again - we're just arguing who does the transform.

It's not "just", it's the point.

> i don't see the point. the
> compositor will have a list of colorspaces it can display (either A screen can
> display this OR can be configured to display in this colorspace, ... OR the
> compositor can software transform pixels in this colorspace to whatever is
> necessary to display correctly).

I don't know how many different ways I can explain the same thing. The compositor
can't know how to transform color in all the ways an application may need
to transform color. I think it is unlikely for instance, that you are
proposing that the compositor support full N-Color, device links, ICC-Max
support, etc., or the infinity of ways that haven't been invented yet to
transform between color spaces. So the core color management requirement
is that the application be able to transform into the device colorspace itself.

> the client simply chooses what colorspace to provide buffers in. it chooses the
> one that is best for it.

A core requirement is that the client be able to know what output device
colorspace each pixel is destined for, and provide a buffer that the
compositor doesn't touch (i.e. it has no source colorspace label
other than don't touch these pixels").

> a colorspace that is enabled is when the display output for that screen maps
> RGB values directly to that given colorspace. i.e. the common default is sRGB.

No. No color transformation by the compositor, so no colorspace.

> the display may be also able to switch to adobe rgb at the flip of a switch or
> by request from the host system (via data lines). it may be fixed and only one
> colorspace is every able to be displayed.

A color critical user won't put up with such things - they expect to
be in control over what's happening, and if a system has proper
color management (core + enhanced), there is absolutely no
reason for them to run the display in anything other than it's native gamut.

> then it's a list of 1 colorspace: "sRGB" :) wehich is the current default/state
> of play in wayland anyway.

No, it's a list of N output display colorspaces, one for each display.

> then you need no colormanagement at all.

As explained, yes, core color management needs support -
control over VideoLUT state, plus registration of the output
display colorspaces + knowledge of which output the different
parts of a surface map to.

> just assume sRGB (gamma2.2 or
> whatever). zero colormanagement protocol or support needed. totally up to
> client. the compositor MIGHT know its colorspace/profile and report it here
> without sRGB listed then. thats how you know you only have 1 colorspace.

I'm not sure _what_ you are talking about. sRGB doesn't come into it.

> thus why i asked if apps will be expected to be able to fallback and DIY
> client-side (and present sRGB).

It's not a fallback, it's core (basic) color management.

> how we're talking about color profiling tools that want to create a color
> mapping/profile for that display so colors display correctly. you need a
> colorimiter to measure output of course to do this.

Yes, and ?

> this could be nothing more than a "1:1 do nothing" colorspace. that means R,G
> and B values are transmitted with no changes. changing the content of your
> buffer sends different signals that the colorimiter can read and thus be used
> to create a color profile/mapping for your display.

Right - the sort of thing that is provided by a core/basic color
management support.

> i don't get why you need so much complexity.

It's the simplest possible support, (hence calling it "core").
It's needed internally anyway for a compositor to implement CMM
operations for "enhance" color management.

> ummm i'm talking about the values of pixels. RGB. what physical color does
> #ff0000 produce? #00ff00 or #0000ff or #880000 or #008800 etc. etc. - that is
> what colormanagement is all about.

No it's not. That's just one aspect of it. The main game is in
how one device colorspace is transformed into another.

> it's about knowing the physical wavelengths
> of light produced when those values are displayed by a screen and then
> ADJUSTING the values provided in order to display the correct physical color.

Hmm. Not really. Mostly a lot of other stuff has to go on top of that
to make things turn out how people expect (source colorspace definition,
white point mapping, gamut clipping or mapping, black point mapping etc.)

> a list of "just 1 colorspace" matches your core concept.

No. See above, and my original sketch.

> the compositor MAY NOT transform. it doesnt have to. it can lie. as long as it
> knows the colorspace/profile of the output and reports that as the one and ONLY
> colorspace supported in the list, then you have what you want. right?

It's a poor approach to rely on the "null transform" hack. It's clumsy,
doesn't convey the actual intent and expectation of operation, and leads
to complications. For instance:

* Null transform is a hack. Only under particular conditions
  (matrix profile with equation defined per channel curves)
  is a profile "exactly" invertible (i.e. to floating point
  precision). Use a LUT for the per channel curves (such as the
  original sRGB profile), and it's not quite perfectly invertible
  (although it may be to low precision). Use cLUT based profiles,
  and it certainly isn't. So it has to be declared to be
  a special case and assumed to be a null transform.

* Deciding what does and doesn't correspond to a null transform
  needs to be decided. Same exact profile ? Same tags ? Same
  description string ? What ?

* If a surface straddles two displays, then labeling all the pixels
  with one of the two displays profile is not the same as not
  touching the pixels.

* What happens at startup, before the output display profiles are
  loaded into the compositor, or if there is no display profile ?
  How do you create a null transform to do an initial calibration
  or profile ?

A simple "don't touch these pixels" flag avoids all this.

> extensions can be mandatory. if clients in the greater part cease to work at
> all without the extension present and working in a specific way.

I don't see how any of that is an immediate or even long term issue. Wayland
applications work currently without any color management support. Adding such
support expands the range of applications (and hence users) that can use Wayland.

Graeme Gill.