[Openicc] CUPS Color Management under Linux... (what is to do ?)

[Chris Murphy]

Lots of explanatory text, so I have a summary conclusion at the very bottom!



On Feb 10, 2011, at 12:21 AM, Kai-Uwe Behrmann wrote:

> Am 09.02.11, 11:26 -0700 schrieb Chris Murphy:
>> On Feb 9, 2011, at 9:46 AM, Jan-Peter Homann wrote:
>>> 
>>> PDFtoRaster
>>> It is important to define, how the current valid cupsICC profile is merged into the print workflow:
>>> - placed as PDF Output Intent in the print spool PDF (this needs a e.g. specialized CUPS filter to do this), before it is send to PDFtoRaster. In this case PDFtoRaster don`t needs any configuration for the cupsICC profile.
>> 
>> I think the most appropriate place is right at PDF print spool generation time. Obviously the ideal is for every PDF print spool file to perfectly state its case in all respects, including color intent and how it is to be converted for printing. But I'm not familiar enough with what actually produces the PDF print spool file to know how reliably it will tag objects correctly, including the setting of (at least) a default OutputIntent.
> 
> Where should the OutputIntent come from? From application, if not from CPD, if not fall back to cupsICC?

Application, then CPD, then *cupsICCProfile, and then ?? - probably the last fallback is leave it /DeviceXXXX.


> 
>> If the generation of the PDF print spool file is centralized, and can be made consistent, great. Then pdftoraster, pdftops, pdftotiff, pdftoOTHER all just need to share some code to properly interpret these PDFs with the help of Ghostscript, to produce consistent results as raster, postscript, tiff, and OTHER file formats that represent the intent of the PDF. Also, if this is always reliable, then we can enable our explicit color management off switch for calibration and profiling devices very literally as well (i.e. no ICCBased objects, no OutputIntent, and that's the off switch). So is there some single library or process that all applications can use to produce a PDF print spool file? I suspect not, but have to ask.
> 
> A convention to opt-out of colour management could as well be
> DeviceXXX + OutputIntent. Thus its clear the PDF/A/E/X comes from a CM aware side and its intention is no to override the embedded destination profile.

Yes I agree. It is what I recommended Apple do years ago. (The catch they ran into was they banned /DeviceRGB and made forced assumptions what that was when it was written.) 

The "dumb" applications will produce objects in a PDF print spool file that are /DeviceRGB, and then the CPD (it writes out PDF print spool file?) would substitute sRGB when either the user chooses an explicit destination profile (becomes OutputIntent) or they leave it at default in which case *cupsICCProfile becomes the assumed destination. But if the user chooses instead a "color management off" in the CPD instead of a destination profile (same popup menu) then the CPD must *ENSURE* that objects are /DeviceRGB and set some OutputIntent, probably a default based on media type settings. 

If those source objects are not set correctly by the CPD, we have a problem.

For this to be really consistent, you'd have to have the CPD *strip* ICC profile metadata if the application submits tagged objects for printing. If those objects are ICCBased, and the user chooses in the CPD a "no color management" option, are we really going to have the CPD responsible for changing ICCBased objects to /DeviceXXXX? Or is it easier to pass a "color management OFF" flag as metadata, and then for something downstream to know to ignore all ICC profiles in the PDF print spool file?


> 
> The model of DeviceXXX and no OutputIntent appears to me as fragile. What if some filter assumes this PDF as coming from a CM unaware source and tries to fix that, e.g. remote?

Well if the CPD is 100% reliable in setting an OutputIntent no matter what, EXCEPT when "no color management" is chosen by the user, then that means the absence of OutputIntent is the same as "no color management" and should be reliable.

But it's all a matter of how much control there is. The profile target case is so unique and so rare, it might not be a bad idea to consider an explicit tag. Either ICC profile format that is a message to the CMM. Or in CUPS PDF metadata that is a message to either:

pdftopdf refilter: which if it saw such a tag would strip all ICC metadata from the PDF, in which case there'd be nothing in the PDF for downstream to convert (but it could still one day or on some platforms cause assumptions for conversion to be made, so it's still not a guarantee, close, but not a guarantee).

pdftoraster and pdftoXXXX: again if they see it, ignore ICC metadata and don't ask for conversions. This means hardcoding behavior in those filters. Might work better than a prefilter but requires specific instances of these filters to exist on the platform, or you could still have the same assumptions for conversion downstream by the render/raster process.)

Render/Raster: By the time we get here, it seems that it's entirely possible the "do not convert" metadata tag could possibly have even vanished. I don't know how reliable metadata in PDF can be carried downstream. But if it's reliable, the message could be honored here.

CONCLUSION:
As I think about it, the most reliable "no color management" tag is a message directly to the thing that does the conversions. And that's the CMM. So the message would be a particular kind of ICC profile.

Of course we'd be best off getting such a profile endorsed by the ICC, but I don't know that's necessary. If we get lcms on board, that's 1/2 the battle right there since it seems our focus for a color managed print pipeline right now is CUPS+GhostScript+lcms. We know ICC profiles are passing through all the way to the CMM or we wouldn't get conversions (assumed or otherwise), so this makes some sense.

My preference is that this ICC profile would be a header only profile, no body, and class 'spac' (ColorSpace Conversion) to differentiate it and hopefully avoid it being obviously useable and embeddable like very common 'mntr' (display device) class, and 'prtr' (output device profile) class profiles are. I'm not sure what the PDF spec thinks about 'spac' class profiles however...could be a sticking point.


Chris Murphy