[Openicc] _ICC_PROFILE in reality

[Kai-Uwe Behrmann]

Am 27.05.2011 09:44, schrieb 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.

Thats the CMM view of things. And for that alone I would agree with you.

However, from the system point of view it makes a bigger difference if a
user specifies a source profile or if she/he specifies as well the
output profile. Most APIs try carefully to abstract output from intput.

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

As a separate API it could work. I guess Cairo needs such a thing for
output to different medias or different printing presses involved for
one PDF document.

>> 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.]

Good. For Oyranos I think we check for device links on input images.  So
a user is free to specify custom gamut mappings. That was implemented
due to your former request in an other email thread.

The next logical step would be to use that as well for display colour
correction. Then all the actual automatisation for that in Oyranos would
fall flat. The client had to setup regions by here/his own and specify a
device link to each monitor region.

To utilise that more convenient, we could start to make the output
device transparent and let a array be specified for each physical output
device. That sounds rather complicated with much work involved but could
end in a cleaner design.

An other way would be to specify the output device link profiles through
the options to the ICC module. During splitting the dummy output into
real device transforms the device link array from the CMM options could
be used instead of the automatic detected output devices.
That is kind of a hook in the architecture. It would only work for the
multi monitor display correction. It will not work for mirrored outputs
as Oyranos has currently no access to any Xorg pixel buffers.


kind regards
Kai-Uwe