[RFC wayland-protocols] Color management protocol

[Graeme Gill]

Richard Hughes wrote:
> On 20 December 2016 at 07:22, Graeme Gill <graeme2 at argyllcms.com> wrote:
>> Or be prepared to re-visit Wayland's fundamental design decisions
>> if they turn out to be based on a false premise.
> 
> I don't think that's fair. I think Wayland is the opportunity to upset
> the status quo with color management and do correctly what what never
> possible with X11.

I think it is fair - a lot of push back is along the lines of
"that's impossible - Wayland doesn't work that way", which
if taken to a logical conclusion, (maybe) implies that Wayland is
incapable of sporting color management.

Assumption: "Applications are oblivious to the output their
pixels are rendered to"

Reality: An application needs to know the output it's pixels
land on if it is to present them in the correct output specific
colorspace.

Assumption: "The compositor is able to do all the transformations
necessary to render applications pixels to the output device"

Reality: It may not be practical for a compositor to have the
color conversion machinery capable of doing the transformations
in the manner and to the precision that an application requires.

Assumption: "Graphical system API's can be divided into
application operational API's, and Management API's.
Wayland need only cover the former".

Reality: Some graphical functions are both operational
for one type of application, and management for other types
of applications.

Assumption: "All management functions can be incorporated in
the compositor"

Reality: Some management functions require full blown applications,
and can't practically be incorporated in each compositor,
nor tailored to each compositor.

So if the realities challenge the assumptions, then
either clever means need to be invented to get things
to work within the assumptions, or the assumptions need
to be softened. Saying "it's impossible" doesn't progress
things, nor help bring Wayland up to having the capabilities
of other existing systems.

[ The above of course is, as best I grasp it from preceding
  conversations. ]

> Lets be honest for a moment. How many applications support color
> management on the Linux desktop? We're asking application authors to
> understand things like blending spaces, source and destination
> profiles, vcgt, overlapping windows on different crtc's and horrible
> concepts like that.

Agreed. Easier to access, and default color management framework
is desirable (and for that reason was included in my sketch). But
this shouldn't be at the expense of applications that need more
than that, nor at the expense of color management applications
needed to set things up so that all this can work in the first place.

> As a framework guy, _and_ an app developer I just want to tag one
> surface with a colorspace and then let the compositor figure out all
> the grotty details.

And you should be able to. But what about applications that need
far more than that ? (Ordinary CMM's of the type that are likely
to be practical in a compositor, lack a lot of capabilities
that some applications will need).

> Anything more and the application author will just
> decide it's not worth the bother. To calibrate we just ask for a
> surface that's not going to be tampered with, but we don't want to
> optimize for this super-uncommon case.

I disagree - leave it to be an afterthought, and it will be
done badly or left out completely, crippling the practicality
of color management for the system.

Graeme Gill.