[Openicc] Print Color Pipeline + No Colormanagement

[Kai-Uwe Behrmann]

Am 26.01.11, 17:03 +0100 schrieb Jan-Peter Homann:
> Hello Kai-Uwe, hello list
> May be I´m wrong, because I´m not a developer...
>
> I tried to describe a workflow, where the printer driver is the place to 
> assign ICC-profiles to driver settings. The g-c-m is in this case a central 
> place for applications to know, which profile is currently valid for the 
> driver setting, or if a printout without any ICC based color transformation 
> is should be made.

Central would mean there is one CMS. However g-c-m has started as a 
second or third effort for building a CMS on Linux. I am afraid we have 
now to work out, how to get that different CMS'es working side by side 
without too much trouble. Cooperation by designing g-c-m on top of Oyranos 
and if needed a session specific framework inbetween was not rejected by 
the Oyranos authors.

> Based on this infrastructure we can either have a graphics library which is 
> doing color transformations from document colorspace to the output device 
> (monitor or printer driver setting) or the application itself handles such 
> color transformations.
>
> As the printer driver has a connection to g-c-m, we can be shure, that there 
> is only one color transformation from document colorspace to printer driver 
> setting.

No, that becomes not clear through the connection to a CMS. It becomes 
clear by placing a CMS in a good and unique position in the print 
architecture. Oyranos or colord can not be designed to control the print 
workflow. PDF processing and spooling is out of scope for these CMS'es. 
They merely provide answers to question and that to a different degree.
Btw. colour conversions will very likely be performed by lcms inside 
Ghostscript or an other PDF rasteriser.

> If printer driver settings incl. assigned ICC-profiles could be exported and 
> imported, we have several workflow scenarious both for standard and color 
> expert users:
> - driver settings with cannend profiles as part of the driver standard 
> installation
> - vendors of print media offering downloads of drivers settings incl. ICC 
> profiles

That is all in scope for the Oyranos CMS.

> - esay possibilty to build up an infrastructure for profiling services

That could be configured as a specialised setup.

> - easy possibility to start ArgyllCMS as profiling engine direct from the 
> driver and assign the Argyll-profile automatically to the driver setting.

That needs some hooks or at least a better ICC opt out mechanism, than 
what currently is planed with CUPS.

> My question to Kai-Uwe
> Would be a similar workflow possible with Oyranos ?

Possibly yes. However a clear plan on how to explicitely opt out of 
colour management is needed or we very likely end with much gessing for 
profiling.

> Best regards
> Jan-Peter

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


> Am 24.01.11 16:50, schrieb Kai-Uwe Behrmann:
>> Am 24.01.11, 16:03 +0100 schrieb Jan-Peter Homann:
>>> the driver sends "ProfilingInhibit" to colord.
>>> If the testchart will be printed, the Gnome Color Manager tells the 
>>> application / service which renders the data for printout not to apply any 
>>> color conversion.
>> 
>> As Richard and Tim have now "no colour management" option designed, its 
>> very specific and works only inside g-c-m. There is no obligation that this 
>> works relyable together with any other CMS.