[Openicc] Print-Color-Pipeline: Learning from TurboPrint and Photoprint

[Jan-Peter Homann]

Hello to all,
Reading the e-mails about implementation of cupsICC based print 
colormanagement workflows, it seems, that we are far away, from having a 
reliable and easy to use ICC based print workflow.

Most dicussed problems are based on the assumption, that ICC based 
printing has to to implemented in the PDFtoRaster Filter with the 
OutputIntent as target profile, to allow color management for PDF files, 
ICCbased PDF objects.

As written in my concept for colormanagement under LINUX at the OpenICC 
wiki, a faster implementation would be succesful, if we concentrate in 
the first step on flat color documents. This would deliver ICC based 
color management workflows for following use cases:

- sRGB based print workflow for all "color dumb" applications
- printing of digital images with workingspaces other than sRGB (e.g. 
AdobeRGB, Eci_RGB, ProPhoto etc.)
- printing of graphic arts PDF files which have been rendered to 
standard CMYK workingspace like e.g. SWOP, ISOcoated_v2 or GRACoL

Delivering an ICC based print pipeline for such use cases, will solve 
the print colormanagement needs of 95% of all LINUX users today.

How could this implemented step by step ?

1) We need a combination of a printer driver which allows to create 
settings to which a printer ICC-profile will be assigned

2) We need a bitmap based filter for ICC based color transformations 
combined with the printer driver. ICC based bitmap conversion is a 
standard functionality of littleCMS

Avialable combinations of printer drivers with offering pixel based ICC 
conversions are e.g.:
- Turboprint (Closed source)
- Gutenprint and littleCMS as part of Photoprint (Open Source)

Turboprint offers functionalities, which are between  printer-vendor 
based "RGB-only" printer drivers and professional RIP solutions with 
integrated colormanagement and printer drivers.

Turboprint allows the printer driver to be profiled both in RGB and CMYK 
mode. Creating printer driver settings, printing testcharts and 
configuring printer profiles is managed dircetly into the driver.
The integrated "bitmap ICC conversion engine" allows to define different 
input profiles for differnt settings.
- Settings with sRGB as input profile will serve the needs of all the 
"color dumb" applications creating DeviceRGB PDF print spool files (the 
vast majority today)
- Settings with other RGB input profiles like e.g. Adobe RGB serve the 
needs of photographers and digital imaging specialist
- Settings with CMYK input profiles serve the needs of print orientated 
graphic designers

PDFtoRaster or PStoRaster do not need to do any colormanagement. 
GhostScript and poppler can used, as they are (even the older versions)

Tehnically, Photoprint offers comparable functionalities with a 
combination of Gutenprint ans littleCMS, but with a UI targeted to the 
needs of photoenthusiasts.

Making ICC based printing simple as possible for the users needs in my 
eyes a focus on following topic:
- How can we a link between printer driver based color management and 
the UI in CPD (Common Print Dialogue).
- We need an abstraction layer, that e.g. both Turboprint or a 
combination of Gutenprint and littleCMS could communicate new created 
settings to the CPD.
- we need an abstraction layer, that the input colorspace could be 
configured through CPD
- The standard input colorspace in CPD / printer driver would be sRGB
- The power user has the option to choose other input space through CPD 
which setup the printer driver

I think, the described workflow steps could be implemented for 
Gutenprint, littleCMS and CPD through a GoogleSoC 2011 project

After this, we could go futher by implementing a communication layer 
between application and CPD, so that the the document colorspace of the 
docucument to be printed will be used automatically as input colorspace 
for CPD. This could e.g. realized through Oyranos or g-c-m/colord.

Question to Zedonet (Turboprint developers):
Would you support the described workflow approach ?

Question to Alastair M. Robinson (or others)
Could you be a mentor for a GoogleSoc project for reusing or enhancing 
the code from Photoprint for implementing the described workflow ?

For the color geeks:
If we have established the described link between the printer driver 
setups, associated profiles and CPD, we have a good basis for getting 
the correct profile for the printer driver setting through the CPD 
selector. We can than  attach the printer profile automatically as 
outputintnt through a PDFtoPFD filter in CUPS befor PDFtoRaster is applied.
So the described worklfow for "flat color documents" is a perfect 
prepararation for more complex PDF based printing workflows

Best regards
Jan-Peter






-- 
----------  Please note the new adress --------------

homann colormanagement --------- fon +49 30 611 075 18
Jan-Peter Homann ------------ mobile +49 171 54 70 358
Cotheniusstr. 3 -------- http://www.colormanagement.de
10407 Berlin -------- mailto:homann at colormanagement.de