[Openicc] Workingsspace vs. late binding

[Jan-Peter Homann]

Hello list

We are already discussing three different approaches to colormanagement:

1) Central working spaces and consistent color
-------------------------
This is a design centered concept:
- Same RGB-numbers for different objects results always to the same 
color appeareance
- If R=G=B you got gray

 From Input to print, there are at least two color conversions:
Input->workingspace->print output

If you are being a webdesigner, you get used to the sRGB workingspace 
and it would be very bad, if your known color numbers suddenly have a 
very different appeareance.

The best way to serve this approach, is to force all imaging solutions 
to convert color to the workingsspace

For most graphic designers, this is a fine working workflow:

RGB-workingspace: sRGB
CMYK-workingspace: SWOP (America) Euscale / ISO (Europe)

RGB-data with other embedded profiles are converted to sRGB to preserve
integrity of color numbers.


2) Late Binding ICC-workflow
----------------------
This is a workflow according the ICC-standard with the goal, to avoid 
unneeded color conversion.
image data is leaved in the input colorspace. Artificial RGB-data stays 
in the colorspace it was original created.
If assembled together in an bigger document, the data is NOT converted 
to an workingspace.
Only during printing or during export wirh format conversion, the 
individual objects are converted to the output space.

This is approach is implemented in following standards:
- PostScript with individual CSA,
- PDF with ICCbased colorspaces,
- SVG

It is also e.g. implemented in following OS or Applications:
- MacOS X Quartz
- Adobe InDesign
- Scribus

For shure, it is possible to write programmes, which are conform to this 
approach and conform to the possibilities in PostScript, PDF etc...
But the danger is, that we get an inflation of profiles. The profile 
chain is breaking, if one object is opend in an applications which 
ignore embedded profiles and can´t embed it.

Also, working according numbers is not possible.

Normal designers are often mixed up, with this workflow.

To the last, we have yet no standards for perceptual gamutmapping in the ICC

Even if this concept seems to be a cool, I avoid it, were I can in my 
daily practice. But if other people like it, they should have the 
possibility to work in this way.

----

Result: Programmers should give the users the possibilty to  make the 
choice:
- consistent color, with conversion to the workingspace
- late binding color, with individual profiles for every object.


Third Possibility: Smart CMMs with individual Gamutmapping per object.
--------------------------------------------------------
Such workflows are far away from ICC and a project for reasearch.
It can be interesting for programms, which do automaticly image 
enhancement. ArgyllCMS has such functionalities, so the OSS community is 
also ready for this approach.


Greetings
:-) 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