[Openicc] color-policy vs. color-infrastructure

[Jan-Peter Homann]

Hello list

The discussion here is very exciting. I learn a lot from it during 
writing and reading e-mails.

I learned e.g. how important it is to look at the color-policy (how an 
application behaves in the view of the user) and how this is connected 
to the color-infrastructure.


A color-infrastructure should serve different color-policies well.
If we concentrate first on clear definitions, what policies make sense 
for different types of users, we can define, what a color-infrastructure 
  should be able to serve.

So in this mail, I will write a littlebit on different user-types and 
color-policies

A) Colormanagement should be easy and invisible
-------------------------------------
The user expects, that color looks the same from input to monitor to 
output. The tasks to reach this goal should be as easy as possible, and 
he don´t wan´t to make any decision about converting or preserving, use 
of rendering intents or gamutmapping strategies.

B) I want control
-----------------
The user wants as much as possible control over the color workflows.
Popping up dialogue-boxes which ask him to preserve or to convert an 
object during productions helps him. He wants able to choose different 
rendering intents and if there are better gamutmapping stratgies, 
compared to standard ICC-rending intents, this is nice. But for shure 
the user wants parameters in this gamutmapping strategies to control them.
For complex projects, the user wants to define and save different 
color-policies which give him control about color in the interaction 
between different applications he is using.
This color policies concern:
- preserve or convert objects for different production stages
- rendering intents for different production stages
- special gamutmapping-strategies  for different production stages
- Applying color-corrections via abstract-profiles or devicelink-profiles
- controling the black-generation for CMYK-output or CMYK2CMYK conversions


If we build a color infrastructure which focuses only on the easy-type 
or the control-type, one of them will be always very disapointed with 
the color-infrastructure.



A color infrastructure, which serves both types and all inbetween
-----------------------------------------------------------------
In my view a color infra structure should first serve the control-type.
If he gets tools to define his own color-policies, we can define 
standard-color-policies, which represent standard-users scenarios.
If the user chooses a standard color-policy for his work and if it works 
all fine, than he needs nothing to change.
If the behavior of color is sometimes not like he expected, than he has 
to learn more about the color-policy he is using, to make is own.


Making LINUX the coolest colortool on earth ;-)
------------------------------------------------
With littlecms and argyllcms, there are really powerful color-tools 
available for LINUX. To make LINUX the coolest colortool on earth, we 
have to think, what to do with this tools.
argyllcms is a tool, which serves the control-type incredible good.
But even for me as an colormanagement-specialist, I´m not able to use 
it, because I´m not a user of commandline tools.
I wan´t to give two examples, where the combination of the 
argyll-algorithms and some standard LINUX applications can make some hot 
combinations:

1) CMYK-Output with individual black generation
-----------------------------------------------
Reading the colorsync-mailinglist, prepress users often want to change 
the black generation of the standard CMYK-profiles from the Adobe 
Creative Suite. To do this, they need to buy a profiling software, which 
coasts at least 1000,- $
In argyllcms, this is just a function to use. (Please correct me graeme, 
if I´m wrong). So for e.g. the GIMP, Scribus, Cinepaint or later 
Inkscape, it would be not a big deal to deliver this functionality.

2) Storing color corrections as abstract or devicelink-profile
------------------------------------------------
The GIMP has already tools for making color corrections. But why only 
apply this to GIMP-files ?
To save them as abstract or devicelink-profile would make the possibilty 
to use such colorcorrection in every program which makes use of an CMM. 
This could be:
- finetuning the coloroutput of your printer
- applying standard color corrections during scanning
- using GIMP color corections as an filter in Scribus or other applications
- Applying color corrections in all kind of applications, which do 
fileconversion or automate imaging tasks


One possibilty to do such, is following task:
- Open a TIFF-file were every pixel represents a color like in an 
RGB-chart for profiling
- manipulate the tiff-file with the colorcorrections-tools you prefer
- convert the manipulated TIFF to an textfile
- calculate an devicelink-profile from the original RGB-values to the 
manipulated RGB-values

graeme, can you describe, if this is already possible with argyllcms, or 
  how much work must be invested, to do this ?


Greetings from Berlin
:-) Jan-Peter





















--

homann colormanagement ------ fon/fax +49 30 611 075 18
Jan-Peter Homann ------------- mobile +49 171 54 70 358
Kastanienallee 71 ------- http://www.colormanagement.de
10435 Berlin --------- mailto:homann at colormanagement.de