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

[Chris Murphy]

At least on OS X, the API is the means to set two flags: object source and OutputIntent (destination profile and implicit source profile for device color). The application doesn't directly set these. It has to ask for it to be set via an API. And then only later if the two flags (color spaces) are correctly set, is color management disabled at the raster stage.

Putting objects into DeviceRGB/CMYK/Gray/N, instead of ICCBased color space, with a required OutputIntent could be a way to inform the system to not perform color management. But as Graeme points out it could be a different flag entirely. Also, I don't know what the print spool file format is in on Linux, so perhaps that language is more easily extended than PDF.

PDF/X-3 is just one possible model. It doesn't have to be followed exactly. But it's a good model. (I'm calling it a model because we can follow its workflow prescriptions without using the actual file format.)

PDF/X-4 which adds transparency support to PDF/X-3. As I've implemented Ghostscript based proofing for high end clients, I'm confident its transparency support works well.

PDF/X-5 implements externally referenced images and ICC profiles, which could come in handy.

PDF 2.0 spec will add explicit BPC (black point compensation) support in the file format, which means the ability to set a per object flag for BPC on or off. And that should be considered since perceptual and relcol transforms aren't ideal for most images, in an ICC v2 context. (In v4, perceptual would be the default intent. In v2, relcol + bpc should be the default.)

You may want multiple OutputIntents. Currently all of these specs use just one, following a "one PDF, one output device condition" sort of philosophy. But it's imaginable having a single print job for a small book and cover, where there are different intents for the cover, and the interior stock. Or a book that's mostly black and white but with some color image inserts in the middle of the book.

Anyway, I think in the near term PDF/X-4 along with BPC support make the most sense to me.

Chris Murphy

On Nov 16, 2009, at 12:10 AM, Kai-Uwe Behrmann wrote:

> Am 14.11.09, 17:11 +1100 schrieb Graeme Gill:
>> Chris Murphy wrote:
>>> filter, and also ColorSync) to not convert the target. Presently on Mac OS the
>>> application of choice is Photoshop, with which we are presently having problems because
>>> the No Color Management based PDF spool file has different profiles set for the profile
>>> target object, and OutputIntent, causing ColorSync to color manage. It autoconfigures
>>> newer print driver settings correctly, but the PDF spool file is malformed, so we get a
>>> converted profile target.
>> 
>> Yes, basically this is a really dumb API for turning color management off.
>> The right way to do it is to have a flag that turns color management off,
>> rather than relying on the software to figure out what profile is being
>> used for the end device, and labeling the file as already being in that
>> space. It's easy to demonstrate that this is sematically incorrect -
>> if you were to spool the file and then replay it after the device
>> profile has been changed, it will print incorrectly.
> 
> I am not familiar with such a flag. So I may ask, where does this apply to 
> which API? The print API while sending data which gets converted to PDF?
> The CMS, which is responsible to do the colour conversion or has in that 
> special case to omit a conversion? ... or the spooling system? ...
> 
> 
> Following  Chris' explanation, a print system "correctly" supporting 
> Device(RGB/CMYK/GRAY/N) in PDF/X-3 will have a path to pass all colour 
> management conversions unaltered. Could this become a simple means of 
> implementing Mike Sweets less is more scheme of hiding CM controls? 
> It would mean generate according targets and send them through CPD as file 
> to the selected printer.
> 
> 
> Still unresolved is the per paper ICC profile selection. To solve that 
> point CPD would be in need to add custom entries to non traceable 
> variables. These are mainly media and ink types which a driver has 
> currently no way to know of in a programatic manner.
> 
> 
> kind regards
> Kai-Uwe Behrmann
> -- 
> developing for colour management 
> www.behrmann.name + www.oyranos.org
> 
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc