[Openicc] [Gimp-print-devel] [Printing-architecture] Colour

[Michael Sweet]

On Nov 11, 2009, at 9:45 PM, Chris Murphy wrote:
> ...
> So really the color options for the driver would be:
>
> (*) Manufacturer named default color matching method. Example:  
> "Epson Standard (sRGB)" and possibly provide a popup menu for  
> additional manufacturer defined color matching methods, again  
> example: "Epson Vivid" and "Adobe RGB (1998)" which are typical of  
> various Epson CUPS drivers on Mac OS X.
>
> ( ) System color matching. Example: "Oyranos"
>
>
> That's really it. The user needs to pick between a proprietary color  
> matching method just because that default is what the major print  
> manufacturers tend to want. If that's not a consideration at all  
> then no UI even required. Just normalize correctly behind the scenes  
> (and I can go through various combinations of all of this from very  
> simple to very complex).
>
> And I'd definitely avoid having a No Color Management or Off option  
> in the driver UI. That's even more confusing. An application that  
> needs a completely raw path needs to request that path, that way  
> it's consistently chosen correctly rather than depending on the user  
> to do it. Plus such an application is a very special use case, and  
> is a huge hurt me button for most users, best not directly exposed  
> in the UI. Document the off switch that's under the hood, and have  
> an application that explicitly asks for that behavior.


OK, my $0.02:

For the general case, I actually think you want no color controls. If  
a printer driver provides ICC color profiles, the printing system uses  
them to convert all color data in the document using that profile  
(document color -> PCS -> device color). If a printer driver says to  
use a standard color space (sRGB, AdobeRGB, etc.), then that is  
implicitly the device color space. Let the printer drivers actually  
support the color space they advertise and do their best to reproduce  
the colors - we all know they will not exactly match the screen since  
there are too many variables to account for: screen, printer,  
lighting, humidity, temperate, marker (ink/toner/wax/etc), media type,  
resolution, eyes, marketing segment for a printer, etc.

One of the biggest problems we have with Mac OS X color management are  
the color controls. Too many users try to tweak every knob we have,  
and too many drivers provide extra knobs that interfere with managed  
color reproduction. The best advice we can give to our users is to  
turn off all of the vendor controls (if necessary) and leave our color  
controls set to the defaults.  If Linux wants to avoid the "mistakes"  
of the Mac and Windows world, eliminate vendor controls and minimize  
(or eliminate) the "standard" color controls. Let the "expert"  
applications provide controls for color profile and rendering intent,  
which is equally important to make out-of-gamut colors look  
reasonable, and leave those controls out of the standard/general print  
dialog.

....

 From the point of view of a color-managed workflow, the ideal color  
space for printer drivers is DeviceN, i.e. a 6-color printer gets 6  
color channels, with the separation defined by the ICC profile for  
that printer, media, color mode, etc. However, the reality is that we  
don't have tools to create or the infrastructure (at least on Mac OS  
X) to handle profiles with more than 4 channels, and thus most drivers  
take RGB or CMYK and map it to DeviceN as needed. Because of this,  
custom printer profiles are of limited usefulness in a printing  
workflow - you can (and many people do) tweak the output for a  
particular set of printer, inks, and media, but the results are not  
ideal because you are not manipulating the color in the printer's  
native color space. Moreover, many high-end printers now provide so- 
called "closed loop" profiling on the printer to normalize the output  
for the current supplies and environment, making the "traditional"  
manual profiling workflow unnecessary.

___________________________________________________
Michael Sweet, Senior Printing System Engineer



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/openicc/attachments/20091112/1bbf0e8d/attachment.htm