[Openicc] Print and monitor Color Pipeline

[Chris Murphy]

On Jan 26, 2011, at 3:05 PM, Jan-Peter Homann wrote:

> Hello Kai-Uwe and all,
> I still think, that colormanagement from the document-colorspace to monitor and to a print setting should be done with the same technology. This should be done
> - best through an systemwide graphics library or
> - second best solution through an application depending graphics layer.
> 
> Technically different ways for rendering data to the monitor and to the print out does not make sense in my eyes.

Well it does complicate coordinating roll out of any new technologies: new CMMs, if we ever get dynamic or spacially adaptive luminance mapping in a CMM, or adoption of spectral based color management. It's possible to end up with a situation where you can use new features for display but not print, or vice versa.


> If we are beginning in an uncoordinated way to implement ICC based color transformations in islands like e.g.
> - Ghostscript
> - CUPS
> - Printerdriver Addons
> - Application side
> ....
> we will end in chaos like we already have under Windows and Mac OS X.

I think it is a different problem entirely than Mac OS. I don't think we need to be overly nervous about making Mac OS mistakes, because the ideology required to get to where Mac OS today simply doesn't exist outside of Apple. It's anomalous.

Other than bugs, you're probably not going to get substantially different results if you have one CMS+CMM doing conversions for display, and another one doing conversions for print.

You could move to an entirely "display PDF" window server and then dump both display and print streams through GhostScript. *shrug* I'm not sure if GhostScript is well optimized yet for this application.


> 
> 
> 2a) Old School way to print is creating PostScript and using a RIP like GhostScript to create a rasterfile. PostScript is not able to transport an ICC based document colorspace, but there are ways, to solve this issues /especially with Oyranos and/or Gnome Color Manager in the background,

Yeah like you said, nightmare. Clearly the way forward is PDF. I think it's totally fair to consider PostScript legacy and just leave it as deviceCMYK and wash your hands of it. I think on most of Linux that applications themselves produce the PostScript? i.e. it's not produced by a proxy library for an application? If that's true, then those applications can choose to color manage their output and produce devicecmyk PostScript and print it like any other file and it would be color managed correctly.

The road to enabling ICC for PostScript or using the older PostScript color management of CSAs and CRDs I think is a death sentence. It's a rabbit hole that will just cave in on the developers before there's a single user who'd ever even use it.


> 2b) new school is directly to create PDF for the printout. All PDF content would be either DeviceRGB or DeviceCMYK with an Output Intent describing the document colorspace. Colormanagement will be applied after rasterization.

We kinda have to be a little vigilant about this OutputIntent business, because that implies one of the PDF/X formats, none of which presently use PDF 1.5, or higher, which is the minimum version necessary to support ICC v4 output device profiles. So if you want to strictly conform to specs, this is a bit of a hiccup.


Chris Murphy