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

[Chris Murphy]

On Nov 12, 2009, at 2:57 PM, Michael Sweet wrote:
> 
> 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.

I agree with most of this. Although I don't know if printer manufacturers would agree to relinquish their own color controls. I'm not a huge fan of their controls and I think they are a waste of space. But they do likely achieve a major goal for manufacturers, which is platform parity for their products.

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

I don't agree with most of this.

The quality of the RGB->DeviceN "black box" provided by a manufacturer for an e.g. 6-color printer, is what determines how effective profiling it can be. For example the Epson Stylus Photo 2200 had a really piss poor Off (No Color Adjustment) LUT. It was wider gamut than the Photo Realistic or Vivid LUTs, but it had nasty gray balance and seriously clipped detail in shadows. It was worth profiling over despite this, for certain classes of imagery. Other classes, it was best to profile over the Photo Realistic mode.

Newer printers, Epson Stylus Pro 3800 or 3880, for example, the Off (No Color Adjustment) LUT is quite well behaved, even compared to the sRGB or Adobe RGB LUTs offered by the driver. Professional, fine-art photographers have been building custom RGB ICC output device profiles over these LUTs for such professional printers for years, using the manufacturer supplied driver, and have achieved superior results compared to either the sRGB or Adobe RGB LUTs.

There are a couple of products on the market that can build 5+ channel ICC output device profiles. They are old, and expensive, and it's unclear exactly how well they work compared to an RGB ICC output device profile over a good (or decent) RGB->deviceN black box LUT provided by the manufacturer. What is clear is that it's non-trivial making such deviceN ICC output device profiles even if you have the software to build them, or an OS that could support them. The profile target you use is a challenge to figure out how you're even going to print it correctly. And then you have a healthy amount of testing to manually determine what the ink limit should be, since ink limiting is the responsibility of the profile, in this  paradigm, if there is no black box in the middle of the process. And channel cross over behavior, ink limiting and GCR is really non-trivial.

Looking and high-end proofing products, even that is rarely done with DeviceN ICC profiles for inkjet proofers. If it's an Epson inkjet, most products on the market today depend on Epson's HTM (halftoning module), which is the guts of their black box which can accept either RGB or CMYK input. So the inkjet is still profiled as either an RGB or CMYK device, and the HTM is responsible for further separating that out to deviceN. (For dot proofing on inkjet, other considerations are needed.)

So I disagree that "custom printer profiles are of limited usefulness" or that the "results are not ideal." I have much bigger complaints than not being able to peak inside the Epson/Canon/HP black box. I'm annoyed that it's so f'n difficult to reliably print profile targets on Mac OS X without ColorSync sticking its nose into the wrong business. When that happens, the resulting profile is completely FUBARd and that is truly of limited usefulness and results that are not ideal.

Chris Murphy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/printing-architecture/attachments/20091113/63bb59fc/attachment.htm