[Openicc] GoSoC 2011: CPD and Color Management

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

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

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton