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

[Kai-Uwe Behrmann]

Am 10.02.11, 15:02 -0700 schrieb Chris Murphy:
> On Feb 10, 2011, at 2:50 PM, Kai-Uwe Behrmann wrote:
>>> 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.
>
> I don't think any of this is probably easy.

I can imagine that ArgyllCMS and other calibration/profiling tools will be 
likely to produce conforming PDFs to opt out of colour management.

>>>>
>>>> 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.
>
> I'm not saying it should, I'm saying if, based on Hal's suggestion the 
> CPD do this. If not the CPD, then what puts the OutputIntent into every 
> PDF print spool file? If it's up to the application, that means opt-in 
> color management. I thought the context of the discussion was 
> applications had to opt-out if they DON'T want color management, 
> otherwise you only end up with a few apps that opt-in that print 
> correctly.

Agreed, we want primarily a opt-out of colour management.

CPD should place a OutpuIntent into the spool file, _if_ it is available 
from a CMS. This will typical be a user assigned device profile. That 
confirms Hal's and your idea.
But CPD shall not embed any generic ICC profile instead of a device 
specific profile. Thus PDFs might contain no OutpuIntent. Just the later I 
wanted to emphasise.

>>>
>>> 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
>
>
> OK wait. CPD is not mutually exclusive from setting an OutputIntent. It very well may be the mechanism by which an OutputIntent is reliably set for every PDF print spool file.

Agreed.

> If you don't have something ensuring an OutputIntent is set in every PDF: application, and/or CPD, and/or pdftopdf and/or pdftoraster & OTHER (using *cupsICCProfile), then you will have different behavior among applications. There's got to be a sequence of stop gaps, we can't just depend on applications writing PDF correctly.

Yes, in that order. Any following PDF processor can add a new OutputIntent 
but can not replace a existing OutputIntent. Only one OutputIntent is 
allowed per PDF, according to the PDF spec.


Do we recommend PDF/X (A,E) to formal become able to out-out?


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