[RFC wayland-protocols] Color management protocol

[Carsten Haitzler (The Rasterman)]

On Fri, 9 Dec 2016 15:30:40 +1100 Graeme Gill <graeme2 at argyllcms.com> said:

> Carsten Haitzler (The Rasterman) wrote:
> 
> Hi,
> 
> > but is the intent that compositors MUST support color management and
> > applications will fail entirely or fail to display even partly correctly if
> > compositor doesnt support color management or doesnt support the color
> > profile/space requested by the client?
> 
> My intent is directly the opposite.
> 
> An application could choose to fail if core color management is not
> present, or fall back into a non-color managed mode. An application
> that wants to use Enhance color management and finds it is not present,
> could fall back to application color management (although it probably
> wouldn't, because it doesn't want to work that hard), or fall back
> into a non-color managed mode.
> 
> > or will it be expected that apps need to
> > always be able to convert to sRGB for compatibility and then have added
> > colorspace capabilities if it's supported? what is the intent?
> 
> 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.

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

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.

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

> The intent is to enable proper color management. In general, only
> the application will be able to do this to its own satisfaction,
> so core color management is essential. Providing enhanced color
> management is a convenience to applications that don't wish to
> implement their own color management and are content with
> quite limited set of capabilities, as well as making available
> a facility to force default color management onto applications
> that are not color aware.

i don't see a difference between enhanced and core. 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).
2. being able to report what colorspaces are supported at all (either natively
by the display or by emulation)
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).

the only difference is the set of colorspaces wanted by client and by supported
by compositor. core and enhanced are arbitrary labels. 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).

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?

should a client fall back to sRGB is that the intent and otherwise get enhanced
display if color management is there? should a client just give up and exit or
display nothing?

you say the latter. a client can choose to fail entirely, which imho leads to a
far poorer outcome for the user. the vast majority of users out there in the
world have a non-calibrated dumb monitor or maybe don't even have a choice
in screen since it's built in (tablet, phone, laptop, watch ... fridge) and
that's all they will ever have. if this is just intended for enhanced support
then i think this is good.

> If this doesn't make sense to you, then perhaps the best thing
> would be for me to lay out the nuts and bolts of what's happening
> in these different color management scenarios.

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.

if this is mandatory as you say, then i dislike this protocol very much. if
it's optional then i think it's good.

> Cheers,
> 
> Graeme Gill.
> 
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com