[Openicc] GoSoC 2011: CPD and Color Management
rlk at alum.mit.edu
Mon May 2 05:05:37 PDT 2011
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.
> 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
> 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?
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
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."
More information about the openicc