[Openicc] GoSoC 2011: CPD and Color Management

[Kai-Uwe Behrmann]

Am 02.05.11, 08:05 -0400 schrieb Robert Krawitz:
> On Mon, 2 May 2011 09:02:41 +0200 (MEST), Kai-Uwe Behrmann wrote:
>>   This message is in MIME format.  The first part should be readable text,
>>   while the remaining parts are likely unreadable without MIME-aware tools.
>>
>> --8323584-1973729212-1304319761=:5401
>> Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed
>> Content-Transfer-Encoding: 8BIT
>>
>> Am 01.05.11, 19:49 -0400 schrieb Robert Krawitz:
>>> On Sun, 01 May 2011 23:04:56 +0200, Jan-Peter Homann wrote:
>>>> For a CPD based workflow we need a mechanism to synchronize media / driver settings for following use cases:
>>>> - driver vendor provides profiles in the standard installation
>>>> - media vendor provides standard profiles for his media for a given driver
>>>> - profiling service offers profiles based on printed testcharts
>>>> - user is makes his own profiles
>>>>
>>>> Technically this could be solved in two way
>>>> 1) Export and Import of medie / driver settings with an attached ICC-profile
>>>> - The driver must allow to createand export  a media / driver setting with an assigned profile for each setting
>>>> - During import of such a setting incl ICC, the consistency between driver setting a profile is guaranteed.
>>>>
>>>> 2) Integrating the driver setting into the ICC-profil through ICC dictType Metadata Registry
>>>> - In this case, the driver must be able to be setup through one file, which can be driver specific.
>>>> If Gutenprint can be setup by such a file, the Gutenprint-Team can register a Gutenprint specific dictType Metadata Registry entry at the ICC.
>>>> - We than need a mechanism to integrate the Gutenprint dictType entry into a printer profile through e.g. Oyranos, g-c-m / colord, ArgyllCMS or other tools.
>>>> - The CUPS xxxtoRaster filters need the possibility to embed the outputprofile into the raster-file for the driver
>>>> - the driver needs the possibility to read the embedded profile from the raster-file and extract the dictTyp entry for automatic setup of the driver.
>>>> ****
>>>>
>>>> From my perspective approach 2) - ICC dictType is more universal and
>>>> smart compared to echange of vendor specific driver setups with
>>>> assigned ICC profiles. It can espcially combined with all main
>>>> scenarios of colormanagement in the printing chain:
>>>
>>> I think I'd also prefer #2; it would require no integration between
>>> Gutenprint and ICC profiles.
>>>
>>> Gutenprint currently provides a way to serialize a settings object
>>> into an XML representation, and to import that XML representation.
>>> It's currently only used internally, but it's a public API that I
>>> believe would be well suited to this purpose.  I don't understand how
>>
>> Robert,
>> could you provide a link to that API for reference?
>
> It's in the header file xml.h (/usr/include/gutenprint/xml.h),
> stp_xmltree_create_from_vars (serialize) stp_vars_create_from_xmltree
> (deserialize).  Unfortunately, that header file isn't currently
> documented, but it's straightforward enough and I can add some
> documentation after 5.2.7 is released.

thanks, its linked on ColourWiki

>>> the higher level color stuff works well enough to do the layering work
>>> (and I don't have time to architect it), but I'd be happy to work with
>>> someone who does.
>>
>> Could you locate the needed architectural work inside the following diagramms?
>> http://www.oyranos.org/wiki/index.php?titleÞvice_Settings#Printing
>
> The most obvious thing to do would be to extract the color-related
> settings from the PPD file, use them to select a profile, and then
> embed the serialized settings object in the profile.  When the profile
> is passed to rastertogutenprint, extract the settings object from the
> profile.

Agreed. For PPD entries I think an early PPD modification inside the 
client may introduce the least interference during the transportation.

My feeling says it would be good to handle the native Gutenprint options 
in the right place that means on the client side. I would like to see 
the optins somehow embedded in the PPD file too. The rasteriser should IMO 
not interfere in any way with ICC profile parsing on the CUPS server side.
It would be technically a snap, but a unpredictable and thus dangerous 
one.


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