[Openicc] Print Color Pipeline

[Kai-Uwe Behrmann]

Am 22.01.11, 18:03 +0100 schrieb Jan-Peter Homann:
> Lets imagine, that assigning ICC to driver settings is solved for the current 
> driver. We now have to think about, to make it easy for the enduser to 
> synchronize the colormanagement settings from his application to the print 
> out.
>
> If we look at the colormatch from the document colorspace to the monitor, it 
> is pretty normal, that the application to handle the document is pulling the 
> monitor profile from the system (or delivering rasterized data with a 
> document (source-) profile to the system for output.

Thats the case in monitor profile aware applications, which are few for 
PDF output, or done through the compositing windowing manager. CompICC 
does this.

> The monitor profile itself will be configured on systemlevel (Oraynos, Gnome 
> ColorManager etc...).

... or can even be automatically generated per monitor in Oyranos and 
will be automatically updated after hotplug in CompICC or on request.

> If the printer profile should be configured in the driver, we need a 
> mechanism, that the driver can tell the system, what is the current valid 
> profile for the choosen driver setting.

Not just one way please. Both directions are needed to do a print preview. 
A print preview will improve usability. Peter Sikking has coverd that 
nicely.

> In this case the color workflow from document to monitor and from document to 
> printout would be pretty the same. An internal graphics engine, which can 
> render the document from the document colorspace to raster output on the 
> monitor, can also render the document to a raster print format.
>
> If CUPS is between the document creating application and the printer driver, 
> we need a possibility to transport the document colorspace through the CUPS 
> file:
> - If rasterized data are transported, this could be done through TOFF or JPG 
> with embedded ICC profile
> - I PDF data are transported, the PDF output intent is used.

Again. The print architecture will profit if information is exchanged 
bidirectional. This means the ICC profile, rendering intent and so on.

> This leads to following places where ICC-profiles are configured:
>
> System:
> - monitor profile
> - RGB-source-profile (sRGB) for non colormanagement aware applications

CompICC assumes sRGB as default with a possibility to opt out.
There are two distinct situations, where we have no ICC profile. If no 
profile is attached and if the application is unaware what to do with ICC 
profiles. Both situations must be handled.

> Colormanagement aware application:
> - Document colorspace (RGB and/or CMYK if necessary)
>
> Printer driver
> - Driver setting specific ICC profiles
>
>
> Is this something we can agree on ?

It would be a start. Just the single direction is not so nice. There are 
even more details like target printing. Possibly a graphical scheme or 
table would be more helpful than to reiterate in each different thread 
about the various requirements.

> best regards
> Jan-Peter

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