[RFC wayland-protocols] Color management protocol

[Chris Murphy]

On Wed, Dec 21, 2016 at 5:05 AM, Daniel Stone <daniel at fooishbar.org> wrote:

>I'd like to attack and bottom out the
> non-calibration usecase without muddying those waters, though ...

What about games? I'm not aware of any color managed games. As far as
I know they all assume deviceRGB and are content with the user getting
something rather obviously less chromatic with less dynamic range on a
laptop, and rather more if they have a 4K TV, or a wide gamut display.
Do games typically draw through X or do they use DRM/KMS?

Video. This is such a rat hole of a mess right now. There are
different codecs with different color spaces, and some of the wrappers
imply different color handling on top of this, and then the user
agents all end up interpreting this mess differently so the same video
content can appear differently depending on user agent, and then
depending on platform. It's so bad. In ancient times Apple had
quicktime video pumped through ColorSync with very good performance.
I'm going to guess this involved simple matrix + TRC defined source
and destination color spaces for the transform. I know that Adobe
Flash, about 3-4 years ago, started to do on-the-fly display
compensation if the metadata in the source file enabled it. (I don't
remember if the tag says "I'm sRGB" and therefore Flash color managed
it, or if the tag says "color management me" and Flash assumes it's
sRGB and therefore color manages it.) And all of this would work in a
web browser's cut out area.

Web browsers. Right now all the web browsers are doing their own color
management, haphazardly. e.g. only images with embedded profiles are
color managed. Untagged images, html and css are deviceRGB, there is
no transformation, and thus no display compensation most of the time.
Browser developers have complained color managing every element in a
web page slows down rendering by a ton. Maybe they're doing it wrong.
:-D Also, browser plugins do their own thing, even if the browser has
full color management enabled, this doesn't affect plug-in content. I
don't know if there's any difference between NPAAPI vs PPAPI plug-ins
in this regard.

GIMP, Scribus, Krita, Digicam, Darktable - are all color managing
their content in advance (early binding) and supply device RGB, having
used the current display profile as the destination in a transform. So
they already do display compensation and don't need it to happen
again. So either they've got a bunch of work to do to rip that out if
Wayland is going to do it for them, or they need a passthrough. Web
browsers are a good example of programs that should probably rip out
what they have and have something else completely color manage all of
their content regardless of whether it's native elements or plug-in,
but I digress.

There has been a need for an explicit pass through to avoid any (or
additional) color management, and there are presently programs that
continue to expect that there will be.

On macOS this is achieved by tagging the content with the current
display profile, since source equals destination, the CMM sees this
and does a null transform, it's a noop. But there's no actual,
literal, off switch. If the content is not explicitly tagged, it's
assumed to be sRGB and hence color managed. So it's both opt in (if
you want something other than sRGB) and opt out (you want a pass
through).

On iOS there are no transforms, there is no need for display
compensation because all displays are either sRGB or (recently)
DCI-P3, and apparently they have the quality control to ensure this
level of consistency at a hardware level. Ironically, they've reverted
to closed loop hardware based calibration. Don't underestimate the
power of consistency and ancient ideas!

On Windows, ICC based color management is opt in, there is an API. If
a transform is not requested, it doesn't happen.

On Android, it's the same as Windows except no API, and display gamut,
dynamic range and tone response are all over the map. (And yet the
world isn't ending, even though if you view the same image on 10
Android phones or tablets you will have 10 different experiences).

I don't assume that on Linux any of these must be mimicked. But there
are distinct advantages with mimicking: we'll have a good idea where
the bodies are buried, rather than having something completely
different from any other platform.

-- 
Chris Murphy