[Openicc] Color Management for Ubuntu

[Kai-Uwe Behrmann]

Am 03.05.11, 13:13 -0400 schrieb Ann McCarthy:
> "We want to go with a explicite opt-out approach. All content shall be
> colour managed by default (typical sRGB). A robust mechanism
> for disabling system colour management is a pre condition for that scheme to
> work."
> Please can we avoid this idea that colour management can or should be
> "disabled."

I am not completely sure if you refere to the used term or the general 
approach for opting out of colour management.

> Definitely we need an explicit path for building profiles -- a control that
> says 'I am building a profile, printing/displaying a test chart' or
> something like that very obvious. This is a function that has to be part of
> a color managed system.  Depending on the device, whether it is a printer or
> a scanner or a display that is being profiled at the time, the processing
> path for that 'test chart' process should be configured differently. For
> example, when building a scanner profile -- you probably still want a good
> display profile to be used for viewing assessment of the scan result, you
> just don't want an existing scan profile to be used.

The opt-out is in my understanding some explicite and very specific means 
for a device class, file format and sometimes for a driver and the 
according context. So, I do not see the scan target from your example 
above would automatically be non colour corrected in CompICC on screen.

> When not building profiles, are there scenarios when users want to see
> uncorrected uncontrolled device behavior?  I cannot think of such scenarios.
> Please provide examples of such situations.

I discussed such a scenario with a senior movie software architect. Other 
examples are early colour binding, where applications use capabilities,
which can not easily be found in system colour management. They all want 
the system to stay away from manipulating colours for whatever reason.

A good policy for architecturing opt-out of colour management is to let 
the programmers do more work for opting-out than she/he would have with 
normal API usage, which includes colour corrections. This policy should 
avoid the pitfal of lazyness being undermining colour management systems.

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


> On Mon, May 2, 2011 at 3:26 AM, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
>> Am 29.04.11, 15:20 -0600 schrieb Chris Murphy:
>>
>>  I thought we were discussing this "how to" in the context of the CPD (I
>>> think I have that right-the common print dialog). And also within
>>> GhostScript.
>>>
>>> And also still unresolved is whether this is an opt-in color management in
>>> the print pipeline or opt-out. And I think to answer that we need to know
>>> the same thing for dispay compensation sonwe don't have a disconnect between
>>> display and print by default.
>>>
>>
>> We want to go with a explicite opt-out approach. All content shall be
>> colour managed by default (typical sRGB). A robust mechanism
>> for disabling system colour management is a pre condition for that scheme
>> to work.
>>