[Openicc] Workingsspace vs. late binding

[Kai-Uwe Behrmann]

Your explanations where very interessting. 

One thing I can not agree is the emphasis on sRGB/RGB as default 
workspace in early binding, because of:

1. Artists are invited to see nothing outside sRGB/RGB.
The advantage one device has over an other will been cutted down.

2. Consistent color:
 if one workspace is used - all artwork will look the same,
,this is what it suggests to naive users,
will cause many surprises and the believing in CMS will degrade. 


For working according numbers CIE*Lab is much more confident than any RGB.
Colour naming should be separated from device close representation.
It is the well established base of the ICC standard.

The clear point for an conversion to workspace is: before colour 
changes convert to workspace. It is an easy rule to follow in dayly 
practice. Colour pickers should show the device colours only on explicite 
request. The default profiles are an good way to go with.

There is no simple way with both early and late binding. Late 
binding seems more flexible. Last but not least, inflation of profiles 
seems to me better than inflation of conversion during repeatedly data 
exchange.

regards
Kai-Uwe Behrmann
                                + development for color management 
                                + imaging / panoramas
                                + email: ku.b at gmx.de
                                + http://www.behrmann.name


Am 21.02.05, 19:05 +0100 schrieb Jan-Peter Homann:

> 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
> 
> 
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
> 

Mit freundlichen Grüßen
Kai-Uwe Behrmann
                                + Programmierung für
                                + Farbmanagement / Bilder / Panoramen
                                + http://www.behrmann.name
                                + email: ku.b at gmx.de