[Openicc] _ICC_PROFILE in reality

[Kai-Uwe Behrmann]

Am 27.05.11, 10:27 +1000 schrieb Graeme Gill:
> Chris Murphy wrote:
>> I just expect the OS to handle it. The problem with apps having to do
>> something special to make it work is that so few developers do.
>
> I think this would be possible, but the OS graphic support would
> have to be sufficiently enlightened. For instance, it would
> be necessary for the graphics system to allow arbitrary
> source pixel representation by the application, and then
> allow the application to set a device link type transform
> from that space to the display. The OS/Window manager could then

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.

> manage the spatial aspects. This leaves the application in full
> control over the color transformation. Complications are
> that typically what an application has to display is a composition
> of different elements. Certain image data may be in an arbitrary
> color space with a desire for high fidelity color, but there will
> be other elements defined in different color spaces that need to
> be composited together. You end up with the need for quite a
> sophisticated compositing system. I suspect that many of

The client would need to become able for specifying the compositing to 
device transforms. I am not aware of a source to destination transform 
to occure in a compositing environment.

> the current display composting systems fall short of what I've described
> above in two ways: They don't support arbitrary source representation
> (ie. they all assume 3 component sources), or they don't support
> an device link transform (ie. they assume ICC source profile +
> destination profile).

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.

> When the application handles the whole deal and transforms its sources
> into the device dependent display values, it at least has the possibility
> of getting it right. The developer has to care to do so though.

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?

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.


kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org