[Openicc] _ICC_PROFILE in reality

[Graeme Gill]

Kai-Uwe Behrmann wrote:

> Agreed. And then we would enter an area of very complex requirements
> from application side toward the OS. The actual approach to OS or
> toolkit colour management is "tag your source image" and the OS/toolkit
> does the remaining things. The next client request is to specify some
> options - intents, out of gamut marking, BPC ...
>
> But what you write now about, is a very detailed control about colour
> correction for output devices. Thats a quite huge shift.

I disagree it's a huge shift. It would actually be simpler,
since it separates independent processing steps.
The fundamental necessity is a colorspace transform (device link).
That's all that required. Creating that transform doesn't have to
be part of the compositing API, it can be a separate convenience layer,
with common useful defaults, such as ICC linking.

> agreed to "they assume ICC source profile". The distination profile is
> automatic. So the application developer is "freed" from handling device
> profiles during drawing context setup. At least this widely applies to
> display colour correction. For printing there is traditionally more
> control provided.

By hiding the linking, there is a distinct loss of functionality.
ICC linking doesn't give true gamut mapping. It fundamentally can't.

> My mere feeling is, that there still might be cases left, where clients
> can not be convinced to use system colour management. So the last level
> of control, to put raw values in place, is still needed. Now the
> question is,
> Will it be worth to introduce on the OS/toolkit level the kind of
> sophistication with device links per possible output devices? Or might
> it be simplier for developers and OS maintainance, to allow the few
> applications, who need so much control, to specify a not too much
> convenient way for opt-out and let them do all colour on their own?

I don't see it as being particularly sophisticated, it's just a matter
of decomposing things appropriately, and putting the right defaults in place.

For instance, if the source has a colorspace ID of some kind (not ICC profile),
then the compositor can simply check if it has a transform for that source
ID to the particular display it is rendering to. If not, it can call
back to a function that creates the transform. The default would be
a function that checks for a source ICC profile tag, and if found
does an ICC link to the display profile. The compositor would then
cache the transform. If there is no source profile, it could
use a default (ie. sRGB). An application that cared about things
like gamut mapping could re-implement the callback.
[This is of course equivalent functionality to a pluggable
  CMM, but without the formalism, overhead  and assumptions that it is
  linking ICC profiles.]

> For most applications it will be sufficient to specify a source profile
> and left the remainder to the OS/toolkit. Of course the cloned output
> case should be fixed somehow. I guess that needs more work on Xorg
> internals first.

Most applications get by with "RBG = RGB". They don't need much in the way
of color management. So if you are going to go to the trouble of implementing
it, "do it right".

Graeme Gill.