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

[Michael Sweet]

On Nov 13, 2009, at 4:39 PM, Chris Murphy wrote:
> ...
> ICC profile. If we get the driver configured correctly, then yes we get a valid profile target, without ColorSync involving itself.

That's the kicker - most inkjet drivers use vendor color matching by default, and usually with vendor-specific "enhancements" that don't get turned off when you tell the driver to go into ColorSync mode.  We file bugs with the vendors all the time for this... :(

> ...
> I have looked quite long and hard on Apple's developer web site for documentation explaining the architecture and how to avoid transforms and was not successful. The API to get the print driver to set itself to the proper mode for use with an ICC profile using application color matching isn't locatable either.

The API for setting up an identity transform isn't public but *is* available through developer technical support. Basically this hasn't been included in public documentation because even the "experts" writing profiling software have used the API incorrectly (for various reasons the API is semi-complicated), and we don't want to encourage the use of device color on Mac OS X except when it is actually needed (which is basically only when printing a target or doing application color management...)

> ...
> Yet an off mode for ColorSync doesn't exist. It depends on null transforms. That's the bigger flaw, in my view, because achieving null transforms is complicated. An off switch is much easier, and thus more reliable.

... and thus more likely to be used.  It is hard to turn off ColorSync on purpose - there are very few scenarios that actually require it.

> An explicit off switch is allowed in PDF/X-3, while still implicitly tagging the data. DeviceRGB being persona non grata, by Apple, in the PDF spool file is a big source, in my opinion, of the problems we've been having on Mac OS. DeviceRGB could have (and should have) acted as a fail safe for calibration/characterization/prematching workflows. While a small percent of the market, these workflows are the #2 workflow behind simply leaving the driver set to defaults.

The problem is that DeviceRGB was being used for everything, not just for those cases that needed it, so it was basically impossible to know what the intent was and get consistent output from applications.

>> A very common problem with the Epson drivers is that the Epson color controls are not actually disabled in ColorSync mode! However, bugs like those are propagated to avoid "breaking" existing users' workflows (!?!)
> 
> I have two current drivers for two different Epson printers and neither of them behave the way you're describing. When I set ColorSync mode, the Color Settings pop-up menu changes to "Off (No Color Adjustment)" and all of its color controls found in Advanced Color Settings vanish. Instead, they are replaced by text explaining the profile that will be used when printing. It appears to be the correct behavior. I know older drivers, for way too long, did behave the way you describe. And yes that's all on Epson, but the documentation is weak, and documentation search on the dev site simply sucks.

Epson (and all of the other printer vendors) work closely with Apple engineering, but there are still problems that slip through our combined testing.  The problem I described has come and gone for specific drivers many times, and often re-appears in new drivers the first time we get an update from them - we reject any that we catch, but as you can imagine we can't test every driver and printer so problems *do* slip through.

> So, presently we're unable to reliably print profile targets from Photoshop, using No Color Management (in Photoshop) and Off (No Color Adjustement) in a wide assortment of newer Epson drivers. What happens is, I get a completely borked profile target in printed form. Inspection of the PDF spool file indicates source≠destination, and thus ColorSync is going to come riding in to convert the job.

We are working with both Adobe and Epson on this issue...

> DeviceRGB being set as the color space would avoid this. Content that is calibration/characterization/prematch from an application, has no business being ICCBased in the PDF spool file.


DeviceRGB (like what we went through in 10.4 and earlier) only led to more problems since all output was uncalibrated.  Of course, had we (Apple) adopted and provided an API for creating sRGB (or heck, even GenericRGB) colors in 10.0 then we probably wouldn't have to treat uncalibrated RGB as sRGB (display RGB) today.

___________________________________________________
Michael Sweet, Senior Printing System Engineer



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/openicc/attachments/20091113/9ecfe8bc/attachment.html