[RFC wayland-protocols v2 1/1] Add the color-management protocol

[Pekka Paalanen]

Hi Sebastian and Graeme

On Mon, 04 Mar 2019 13:37:06 +0100
Sebastian Wick <sebastian at sebastianwick.net> wrote:

> On 2019-03-04 12:27, Pekka Paalanen wrote:
> > On Mon, 4 Mar 2019 19:04:11 +1100
> > Graeme Gill <graeme2 at argyllcms.com> wrote:
> >   
> >> Pekka Paalanen wrote:
> >>   
> >> > My failing is that I haven't read about what ICC v4 definition actually
> >> > describes, does it characterise content or a device, or is it more
> >> > about defining a transformation from something to something without
> >> > saying what something is.  
> >> 
> >> The ICC format encompasses several related forms. The one
> >> that is pertinent to this discussion is ICC device profiles.
> >> 
> >> At a minimum an ICC device profile characterizes a devices color
> >> response by encoding a model of device values (i.e. RGB value 
> >> combinations)
> >> to device independent color values (i.e. values related to device
> >> independent CIE XYZ, called Profile Connection Space values in ICC
> >> terms). A simple model such as color primary values, white point
> >> and per channel responses is easily invertible to allow transformation
> >> both directions.
> >> 
> >> For less additive devices there are more general models (cLut -
> >> multi-dimensional color Lookup Table), and they are non-trivial
> >> to invert, so a profile contains both forward tables (device -> PCS
> >> AKA A2B tables) and reverse tables (PCS -> device AKA B2A tables).
> >> 
> >> Then there is intents. The most basic is Absolute Colorimetric
> >> and Relative Colorimetric. The former relates the measured
> >> values, while the latter one assumes that the observer is adapted
> >> to the white point of the devices. Typically the difference is assumed
> >> to be a simple chromatic adaptation transform that can be encoded
> >> as the absolute white point or a 3x3 matrix. The default intent
> >> is Relative Colorimetric because this is the transform of least
> >> surprise.
> >> 
> >> cLUT based profiles allow for two additional intents,
> >> Perceptual where out of gamut colors are mapped to be within
> >> gamut while retaining proportionality, and Saturation where
> >> colors are expanded if possible to maximize colorfulness. These
> >> two intents allow the profile creator considerable latitude in
> >> how they achieve these aims, and they can only be encoded using
> >> a cLUT model.  
> > 
> > Hi Graeme,
> > 
> > thank you for taking the time to explain this, much appreciated.
> > 
> > I'm still wondering, if an application uses an ICC profile for the
> > content it provides and defines an intent with it, should a compositor
> > apply that intent when converting from application color space to the
> > blending color space in the compositor?  
> 
> I think the correct approach would be to first convert from
> application color space to the output color space using the intent and
> then to blending color space. That way all colors in the blending
> color space will fit in the output color space.
> 
> > Should the same application provided intent be used when converting the
> > composition result of the window to the output color space?  
> 
> When all blending color sources are in the output color space so is
> the resulting color. No intent required.

Right, this is what I did not realize until Graeme explained it. Very
good.

> >> > What is the use for a device link profile?  
> >> 
> >> Device link profile use was a suggestion to overcome the previously 
> >> stated
> >> impossibility of a client knowing which output a surface was mapped 
> >> to.
> >> Since this no longer appears to be impossible (due to 
> >> wl_surface.enter/leave events
> >> being available), device link profiles should be dropped from the 
> >> extension.
> >> It is sufficient that a client can do its own color transformation
> >> to the primary output if it chooses, while leaving the compositor to 
> >> perform
> >> a fallback color transform for any portion that is mapped to a 
> >> secondary output,
> >> or for any client that is color management unaware, or does not wish 
> >> to
> >> implement its own color transforms.
> >> This greatly reduces the implementation burden on the compositor.  
> > 
> > Btw. wl_surface.enter/leave is not unambigous, because they may
> > indicate multiple outputs simultaneously. I did talk with you about
> > adding an event to define the one output the app should be optimizing
> > for, but so far neither protocol proposal has that.
> > 
> > Niels, Sebastian, would you consider such event?  
> 
> My proposal has the zwp_color_space_feedback_v1 interface which is
> trying to solve this issue by listing the color spaces a surface was
> converted to in order of importance.

Oh yes, indeed, sorry. We had a discussion going on about that.

Either advertising the main output for the surface, or the compositor's
preferred color space for the surface.

I'm still a little confused here. If an application ICC profile
describes how the content maps to PCS, and an output ICC profile
describes how PCS map to the output space, and we always need both in
the compositor to have a meaningful transformation of content to output
space, what was the benefit of the app knowing the "primary output" or
"preferred color space" for a surface?

Especially if device link profiles are taken out, which removes the
possibility of the application to provide its own color transformation.

Is it the "displayRGB" Chris was talking about? Is there actually a way
for an ICC profile to say "do not touch the values, forward them as is"?

Do I understand right that "displayRGB" is a special-case where the
application provides content already in the color space of some output,
and to facilitate that, the app needs to tell which output it is for,
and for the app to first choose an output, the compositor needs to tell
which output it should be for?

I think I'm starting to see this, understanding that blending space can
be simply the output space in linear form.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190304/8f010b59/attachment-0001.sig>