[RFC wayland-protocols] Color management protocol

Wed Dec 14 06:58:33 UTC 2016

On Tue, 13 Dec 2016 17:14:21 +1100 Graeme Gill <graeme2 at argyllcms.com> said:

> 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".

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.

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".

> 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".

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".

> > 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.

yes. my bad. i misread the replies and quotes. i thought you said "not at all"
to the "clients should fall back" path.

> > 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.

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).

> > 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.

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...

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

i again don't see why this is needed.

>  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.

again - we're just arguing who does the transform. 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).

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

> > 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.

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.
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.

> > 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.

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

> > 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.

then you need no colormanagement at all. 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.

> 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.

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

> 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.

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.

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.

> > 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.

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

> > 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.

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. 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.

do we agree or disagree?

> > 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.

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

> > 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.

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?

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

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.

> 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.
> 
> 
> 
> 
> _______________________________________________
> 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