[Openicc] Re: LINUX, Gutenprint / CUPS / Color policies

[almccart at lexmark.com]

Greetings List,

I have recently joined - and am quite interested in the current 
conversation.
As some of you may know, the ICC has a Workflow WG and we are currently
working on writing down system level requirements for color management
-  intentionally not of current implementations but rather "what it should 
be."

Jan-Peter's comments point out some of the issues with color management 
in systems today. 

>Actually, we have four possibilities to apply and use profiles 
>during the printing process:
>
>- colormanagement in the application
>- colormanagement with an ICC to CSA/CRD conversion during Ripping
>- colormanagement as CUPS-Filter on rasterized data
>- colormanagement as part of the printer-driver e.g. gutenprint

Also in earlier posts I saw discussions about metadata carried with the 
content file, profiles 
carried with or referenced from the content file, etc.

I have been thinking about this for some time - and the color space 
dependent policy approach 
does not appear robust to handle the variety of workflows and use cases 
that do exist and need 
to exist - even though I agree that such policy approaches are all we have 
to work with today. 
Unfortunately, the caveat of  "if they know what they want, and if they organize 
their workflow properly" is large enough to drive a truck through. The current failures and 
unexpected results with mixed color type object documents are often due to 
incompatible 'policy' 
assumptions at various points in workflows and distributed image paths.

What is needed to get beyond the limitations of color space dependent 
policies - and is becoming 
at least conceivably practical - is metadata that records what has been 
done to color objects - and 
is carried with those color objects. 

It is a fact that color management can and does occur in all of the above 
functional areas
in a workflow.  It is a fact that in functional area X it is impossible to 
know the correct next
color management operation without some information about what was done 
before - even if you
know the color encoding. FYI - refer to 'image state' related papers on 
the ICC website and in 
ISO 22028.

The equation should be:
"what was done before" + "what the user wants to accomplish" => "small 
number of good options"
In some cases the 'small number of good options' is one - in which case 
the user does not have
to pick anything after having indicated what they want to accomplish.

So for example:
caseA: A digital camera image (initially encoded in camRGB) is converted 
to a working space-WS 
(e.g., LAB or a wide gamut RGB working space) using a combination of a  V4 
camRGB profile - 
perceptual rendering intent - and a WS color space profile - relative 
colorimetric rendering intent. 
In the near future (with new V4 profiles) - that will mean that the image 
in WS has been color-rendered to 
the ISO print-referred reference medium gamut. 
caseB: On the other hand, if a digital camera image (initially encoded in 
camRGB) is converted to WS 
using a combination of a  V4 camRGB profile - relative colorimetric 
rendering intent - and a WS color 
space profile - relative colorimetric rendering intent -- then the image 
will still be referenced to the 
camRGB tbd~monitor shaped gamut.

So -- the user wants to print to a wide gamut printer - if case A -- 
probably the relative colorimetric
rendering intent of the printer profile will give good results. If case B 
- you will need to use the 
perceptual rendering intent of that printer profile.

Note that - it sounds from the example as though V4 is adding complexity - 
this is not the case.
Before version 4 and PRMG - the rendering conditions resulting from 
various profiles and their
rendering intents were less predictable and so did not lend themselves to 
"do next" policies.

So - actually - the policies can become: given the image state, cm 
history, and encoding - plus -
what the user wants to do (in terms of the characteristics of the 
destination and certain preference
aspects)  - recommend '2 -- N' number of options -or- just do the one 
right thing. The GUI presents
the results of the under-the-hood policy assessment. 

I hope the above is not too far off topic.  If it is possible to move in 
the direction of such metadata,
it seems practically conceivable to encode such metadata in something like 
xml, for example.
Such file formats as VDX, and PDF now support such xml metadata - and 
there are probably others?
Also, certain job control - such as JDF - allows for xml extensions.

Regards, 
Ann McCarthy
Chair, ICC Workflow WG
Chair, ICC Developer Conference '05
Research Engineer, Imaging Sciences
Lexmark International, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/openicc/attachments/20050413/e4c1edd8/attachment.html