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

[Chris Murphy]

On Mon, Mar 4, 2019 at 4:27 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:

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

Well, in an ICC context it can be your (the programming infrastructure
designer and builder) choice to only offer perceptual rendering. That
is the only required tag in the profiles under discussion, all of
which are 'display class' profiles. That applies to real display
profiles (colord EDID based, or measurement base) as well as most
instances of "artificial" color spaces like sRGB, opRGB, ROMM RGB and
so on.

In an HDR context this is still an open question, but someone or
something will have to account for mismatches or suffer dramatic
consequences in rendering.


> Should the same application provided intent be used when converting the
> composition result of the window to the output color space?

It can be image specific. Again for ICC, standard dynamic range,
output referred context, it's sane to always and only permit
perceptual. There are use cases for absolute colorimetric, but they
are special use cases and for them to be effective you have to apply
such white point simulation across the entire UI. And because this is
still lacking on Windows and macOS, the way it's handled in those
workflows that require it is, hardware level calibration of display
white point to match print media white point. In that case, an
absolute colorimetric and media-relative colorimetric transform are
the same.

Also, because there is an 'input class' (scanners and cameras), and
'output class' (printers and presses) ICC profiles. I tend to refer to
source profiles (the origin or starting point of a transform) and
destination profiles (the intended or end point of a transform) rather
than referring to input and output color spaces. That is, a display is
not an output. It could be a source or destination, by using its
'display class' profile.

> What would be a reasonable way to do those conversions, using which
> intents?

Always do perceptual rendering. And special use cases need to do
things differently. Quite often, media simulation implies CMYK like
the case of Scribus doing proof simulations, you probably don't need
to get involved in that, just give Scribus a way to opt out of display
compensation by indicating they've already done it.


> Do I understand correctly that an ICC profile can provide separate
> (A2B and B2A) cLUT for each intent?

It's rare outside of the output class and occasionally for input
class. And in the output class case, it's mainly the B2A (PCS to
device) that have different tables, since the gamut mapping is baked
into the profile rather than intelligently/dynamically performed by an
engine. Most often I see output class have one A2B table (device to
PCS), which is what applies in the application display use case, with
the rendering intent choices pointing to that table.

-- 
Chris Murphy