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

[Kai-Uwe Behrmann]

Am 10.02.11, 12:03 -0700 schrieb Chris Murphy:
> On Feb 10, 2011, at 12:21 AM, Kai-Uwe Behrmann wrote:
>> 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.

It is more a convention, of course following the PDF spec. A calibration 
application can send even a ready PDF and is done. CPD is then not at all 
needed.

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

This puts the responsibility into CPD and as well much work. But why? 
Documenting that DeviceXXX + OutputIntent fitting to the device behavior 
as a precondition for calibration is enough. Developers can debug their 
own stuff.

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

Its not easily on the agenda now. Maybe for a future version.

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

Why should CPD do that? It set a local configured ICC profile as 
OutpuIntent. If there is none then there is none and done. A obligation 
for CPD to must set the OutpuIntent can become a burden.

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

As a additional hint it might be fine.


A small comparision for "colour management off" methods in printing:

CPD controls everything
* UI options can be exposed for "no colour management" or "switch off"
* more UI options mean, users can fail etc.
* many new(?) strip and convert capabilities to be implemented in
   poppler/GS
* alternative paths are not likely, e.g. direct CUPS user, command
   line

DeviceXXX + OutputIntent
* no UI option needed in CPD, its a application option
* flexible to be used on the command line, etc.
* useful for opt-out in apps, e.g. proofing
* conforms to PDF/X (A,E) spec

DeviceXXX - OutputIntent
* no UI option needed in CPD, its a application thing
* flexible to be used on the command line, etc.
* useful for opt-out, e.g. proofing
* cupsICC might jump in
* not well defined by the PDF spec(?) and spool files might get "fixed"
   elsewhere



kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org