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

[Gerhard Fuernkranz]

Am 11.02.2011 10:58, schrieb 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

And what about printing arbitrary (although still PLRM and PDF spec
compliant) PS and PDF documents, coming from abitrary sources (e.g.
downloaded from the internet, or received from a friend, business
partner, etc.)? IMO this is an important use case too, and "flat only"
might be a severe restriction.

I also don't necessarily agree with "a faster implementation would be
succesful, if we concentrate in the first step on flat color documents".
For instance, ghostscript does already support PS and PDF color
management, as defined in the PLRM and the PDF specs. Basically it's
just necessary to tell gs the desired process color model, color
profiles (or CRDs), default color spaces to use, whether to turn the
remapping of DeviceXXX spaces on or off,... The PS/PDF to raster filter
would just need to setup this stuff (e.g. in a postscript prologue sent
to gs) and then feed the PS/PDF documents to be printed into gs -
everything else is done by gs [I used this approach for instance here:
http://sourceforge.net/projects/m2300w (I did not implement proofing and
other high sophisticated RIP capabilities though, but just some basic
stuff, but additional features could be certainly added, if desired)]

Finding out the the right color profile and other parameters to use for
the print job needs to be done anyway. Setting up gs correspondingly is
IMO not so much additional work as you may believe. And if you have a
solution for PS/PDF, then you have already a universal solution, as
other graphics formats could be converted to PS/PDF first (of course the
other XXXtoRaster filters can still be color-enabled too, in a 2nd step,
in order to avoid the PS/PDF overhead).

[A potential issue may be the quality of ghostscript's color
transformations. In 7.x it was lousy (much banding). In 8.x it has
improved significantly, but a small quality difference to a
transformation performed outside gs (e.g. with lcms tools) was still
noticeable. I don't know, how things have developed in the mean time - I
never used/evaluated the new gs versions so far.]

Regards,
Gerhard