[Openicc] printing GUI vs. printerdriver, LINUX colorinfrastructure

[Jan-Peter Homann]

hello list

It seems, that in the last mails, the term "printerdriver" was used with 
very different meanings. If we want to build a transparent 
color-infrastructure for printing, we need a better, definition, what a 
printerdriver is. For me, it makes sense to make a difference between 
the printing GUI and the printerdriver.

The printing GUI is the userinterface, where the printing settings for 
the actual job are specified.

The printerdriver is driving the printer directly. Mainly this is the 
rasterization for the printed dots, some kind of colormanagement and 
paper-handling according the printsettings, the user has made in the 
printing GUI.

How should printing-colormanagement be done ?
------------------------------------------
As described in mails before, we have four main possibilities to 
transform color for printing:
1. colormanagement in the application
2. colormanagement as CUPS-filter
3. colormanagement with CSA/CRD in the PostScript-RIP
4. colormanagement in the printerdriver

In the printing GUI, the user should specify, which way of 
colormanagement he is using.

For the professional user, we should offer all possibilities, even the 
possibity to make colortransformations in any combination of the 4 steps.

For the standard-user, this would be much to complicated and a source of 
misconfigurations an unwanted automaticly made colortransformations.

The interaction of the printing GUI and the printerdriver
-----------------------------------------------
If we are talking about color-infrastructure for printing, we have to 
look at the interaction of the printing GUI and the printerdriver.
This is going complex, if users in a network printing to different 
printers, where RIP and driver are running on servers.

During my work as colormanagement-consultant, I have to handle with 
different solutions:

1) Virtual printers for different color-settings
-----------------------------------------------
This is very common in the field of digital proofing, where mainly 1-10 
different color/media-settings are used in a network. I´m doing the 
profiling and profile-configuration for every media and generate a 
virtual printer for every color/media-setting. Every virtual printer 
gets the name of color/mediasetting e.g.

Epson4000_SWOP_semimattpaper
Epson4000_SWOP_standardpaper
Epson4000_newspaper_standardpaper

It is easy to train the users, which printers they should use for 
different jobs. But it is going complex, when you have to handle a lot 
off diffent color/media-settings.

The interaction of printing GUI and printerdriver is low and easy. 
Mainly it concerns paper-handling.

2) PPDs with static user settings
---------------------------------
This is very common in the field of colorlaserprinters. The RIP/driver 
has some predefined standard-settings and allows some users specified 
settings with hard-coded names like "user setting 1" "usersetting 2" and 
so on.
In the printing GUI the these settings can be triggered in the "Options" 
dialogue under the same names.

This is easy to implement in the printing GUI from the view of the 
developer, but the user always need to know, in which case he has to use 
"user setting 1"
I don´t like this possibility.

3) Interaction between GUI and RIP/driver
-----------------------------------------
Such solutions can may interact in one or both directions:
 From application via GUI / Spooler the document-colorspace and the 
rendering intent for the job is automaticly communicated to the 
RIP/driver. There, the color is transformed from the document colorspace 
to the printer/media/driver specified color.
This is very easy to use, but also flexible.

---------------------------------------------------
For a LINUX-colorinfrastructure for printing, this would my preferred 
standard-setting !!
----------------------------------------------------

More interaction is necessary, if some usersettings are done on the 
RIP/driver (eg. profiling, linearization) and this user settings should 
be available with their own name in the printing GUI.
For complex colormanagement scenarios, this delivers often a more 
consistent and flexible printing GUI as the use of 20 and more virtual 
printers for every special printer-setting. Such solutions are very 
common for large format printing, where print-providers have to handle a 
lot of different printing media, linearization-files and ICC-profiles.


colormanagement with CSA/CRD vs. printerdriver
-----------------------------------------------
Using a combination of RIP / printerdriver we have the possibities to do 
colormanagement with CSA/CRD during the RIP-process or with ICC-profiles 
  after Ripping and before rasterization. In the last case, the RIP 
delivers an high-resolution Image in the document-colorspace, with 8 or 
16 Bit per channel. The printerdriver is doing first colormanagement and 
than the rasterition for direct driving the printer.

CSA / CRD
---------
In the first case, the printerdriver can be relativly dumb in the field 
of colormanagement. But we need a mechanism to convert the document 
colorspace to an CSA and the profile for the media-driver setting to an 
CRD. We also need a mechanism, that the the RIP can choose the right CRD 
according the media/driver setting. We also need different CSAs / CRDs 
for differnt rendering-intents, the user specifies in the printing GUI.
If the user specifies absolut colorimetry, the papertone of the 
document-colorspace is only simulated in the ripped objects and NOT on 
areas, where no objects are.
For digital proofing with absolut colorimetry, the CSA/CRD construct is 
not usable.
The CSA/CRD colormanagement-appoach is often used for cheap inkjet-RIPs 
or for colorslaserprinters / colorcopiers.

driver-colormanagement
--------------------
In this case, the RIP is dumb in the field of colormanagement. As 
colormanagement is done on an image representing the complete 
printinout, absolut colorimetry delivers a proper simulation of the 
papertone of the document-colorspace. We don´t need a transformation 
from ICC to CSA/CRD and we also need no configuration from 
media/driver-settings to CRDs for the actual job.
Such architecture is common for digital proofing and large-fromat 
printing, where linearization and individual proofiling are normal steps.

-------------------------------------------------------------------
If standard-printerdrivers are available, which delivers this 
functionality, I would prefer this as standard-setting for LINUX 
printing archtecture and not the CSA/CRD transformation
---------------------------------------------------------------------


Hardcoded colortransformations, ICC-profiles and devicelink-profiles
-----------------------------------------------------------------
Making a good linearization and an individual ICC-profile for an 
media/driver setting is a hard job, wich needs several testprints for 
lineraization and profiling charts, a spectrophotometer and a profiling 
software. Such tools are not common yet in the Open Source printing scene.
But if a good profile for an media/driver setting is available, this 
makes it possible to work with different document-colorspaces and make 
high-uality colormatches to the actual media/driver setting.

Using hardcoded colortransformations are a fast and cheap way for 
reaching "good enough quality" without the need for a spectrophotometer.
Often hardcoded colortransformtions resulting to smoother and visual 
more pleasing results, than ICC-profiles if the printer was not optimal 
lienarized. This is especialy visible in color-blends.

On the other hand, the result of hardcoded colrotransformation are 
always depinding on the document colorspace, which is used.
If the printerdriver delivers a hardcorded colortransformation, which 
converts with good results from sRGB to the printer, the user must 
always work in sRGB colorspace.

If hardcoded-colortransformations in Opensource-Software are used, every 
developer has is own specification. So hardcoded colortransformations 
can not be generated, editet and used with different applications.

ICC-profiles on the other hand, can be generated, edited and used with 
different applications.

Devicelink-profiles are the ideal bridge between hardcoded 
colortransformtions and an open ICC-approach. Devicelink-profiles can 
represent every kind of colortransformation or colorcorrection, which 
can be hardcoded.
They can also be used in ICC-based workflows, when the CMM like e.g. 
littleCMS supports devicelink-profiles.
If devicelink-profiles are used, the generation, editing and usage of 
hardcoded colortransformations can be done with different applications.

It makes e.g. following workflow possible:
- The user opens a testimage in GIMP and prints it out.
- He compares the result on the monitor with printout.
- he is doing some colorcorrections, that the printout better fits to 
the monitor.
- He stores the color corrections as develink-profile and configures the 
devicelink-profile in gutenprint
- Now he can use the colorcorrection made in GIMP during printing from 
all applications with gutenprint.

For high-end colorprinting, devicelink-profiles are also a common 
technology. Source and destination profile are linked to a 
devicelink-profile and may edited for special purposes .

--

If a printerdriver can use devicelink-profiles, it should be possible 
that the devicelink-profile is configurable for special combinations of 
document colorspace and media/driver setting.

If sRGB data is printed to driver/media-setting1, devicelinkprofile1 
should be used. If AdobeRGB is printed to driver/media-setting1 
devivelinkprofile2 should be used.

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.
--------------------------------------


Colorful 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