[Openicc] printing GUI vs. printerdriver, LINUX colorinfrastructure

[Hal V Engel]

On Saturday 16 April 2005 05:33 am, Jan-Peter Homann wrote:
snip
> The main points of this mail together:
> -------------------------------------
> The printerdriver should be able to use CMYK(cm) linerizations and
> icc-profiles
> - colormanagement for printing should be done in the printerdriver after
> ripping
> - the document-colorspace should be sended from
> application->printerGUI/CUPS->RIP->printerdriver
> - the rendering intent for printing should be specified in the
> printingGUI and sended the same way like the document colorspace
> - The printerdriver should use devicelink-profiles if hardcoded
> colortransformations are necessary.
> - the printerdriver should allow the configuration of
> devicelink-profiles for special combinations of document-colorspace and
> media/driver-settings.
>
> Main advantages of this concept
> -------------------------------
> - both hardcoded and ICC-transformations during printing is possible
> - Easy way for printing RGB-data from applications, which don´t support
> icc-colormanagement. In this case the printerdriver uses a
> standard-transformation from sRGB to the media/driver setting
> - Very easy way from the document colorspace to the media/driver
> colorspace, for printing from ICC-aware applications
> - Open to high-quality users like photographers, designers,
> prepress-bureaus or large-format printers, which want to make their own
> profiles.
> - It should be possible to implement with a combination of CUPS and
> gutenprint.
>
> --------------------------------------
> This printing architecture would be in the field of colormanagement more
> flexible, powerful and transparent than the actual printing architecture
> in Windows or Mac OS X.
> --------------------------------------

I have to say that for the most part I agree with Jan-Peter.   I do not have 
any experience with the Mac OS but I have been doing CM on Windows for some 
time now for photography (end to end, camera/scanner ==> printer).  I even 
use CM as part of my process when taking my photos by taking photos of IT8.7 
targets when I am not sure of the lighting conditions and creating custom 
device profiles that are specific to those photos.  I know what Windows CM 
shortcomings are and they are extensive.  Almost nothing works right and the 
only way I have found to implement a working CM work flow is to turn off 
everything related to CM in Windows and use CM aware apps along with a manual 
work flow.  The Windows CM is totally lacking transparency and is 
inaccessible to users that have not had extensive training and it not 
available at all for non-CM aware apps to any user no matter how much 
experience that user has with CM.   Well sounds a lot like what we currently 
have at the systems level on Linux and other open source systems.  The only 
real difference is that there are far fewer CM aware apps available for open 
source systems.  My point being that Windows is only very slightly ahead of 
what is currently available on open source systems.

I should also add that I don't use PostScript printers and I don't work with 
PDF documents.  As a result I simply do not care about the complexities that 
are introduced by the PDF format.  I suspect that most photographers would 
agree with me.  In fact this strikes me as an application issue not a 
printing system issue.   One of the challenges that we face in designing the 
open source CM architecture is deciding what each sub-system is responsible 
for.  I think that any application that introduces application specific 
complexities should be responsible for dealing with those complexities at 
least initially.  We should focus on the general case rather than getting all 
worked up over application specific problems that fall outside of the general 
case.  After all if we can solve (even if the solution is not perfect) the 
general case open source systems will be way ahead of what is available on 
closed systems.

The CM printing architecture described by Jan-Peter would be a huge 
improvement over what Windows currently has.  It would solve the vast 
majority of the printing system CM problems that exist on Windows.  In 
addition, it seems to me that it would not be difficult to implement as it 
requires only incremental changes from the current open source printing 
architecture if we design the architecture for the general case (no system 
level support for PDF CM complexities).

Some one else in another post in this thread wrote "...but ICC is not
the be all and end all of color management!"  This is in part true but ICC is 
the glue that holds everything together.  CM is an end to end process that 
starts with the source image from a camera, scanner or artists drawing and 
ends, in some cases but not all, with a printed document or image.  The one 
constant in that process is the use of ICC profiles to characterize the color 
spaces of the devices in the processing path.  This allows the needed color 
space transformations to happen in a standardized predictable way at each 
point it is needed.  As such it is a critical part of CM that must be 
understood and used correctly by every sub-system along the image processing 
path.  We should not lose site of the fact that it is ICC that makes what we 
are trying to do possible even if there are other things that are equally 
important.