[Openicc] GoSoC 2011: CPD and Color Management

[Robert Krawitz]

On Sun, 01 May 2011 23:04:56 +0200, Jan-Peter Homann wrote:
> Hallo Robert,
> Thanks for your response. I will try to explain more in detail my approach:
> For a color managed print output, it is necessary to synchronize media / driver settings and ICC-profiles valid for the media / driver setting.

Yes.  One settings bundle, one ICC profile.  It just has to be
possible to determine which settings are relevant (not all of them
are; media size and input slot, for example, aren't likely to impact
color).  The Gutenprint core, as of the forthcoming 5.2.7, now
provides that information.

> For pofessional RIP solutions, is is normals to create printing queues with different media / driver settings and to define the output profile as part of the queue configuration.

Again, understood.

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

> 2a) application based printer colormanagement
> The printer-profile is configured in the application and the application delivers prematched raster-data for the printer. This is. eg.g the case with Inkscape today.
> The only enhancement the Inkscape team has to do, would be to embedd the printer profile in the raster-file fro the printer, which is a quite simple task.
>
> 2b) OS based printer colormanagement
> Under LINUX this handled through cupsICC and different xx_to_Raster filters like e.g. GhostScript or Poppler. The main task here would be to embedd the printer profile in the raster-file fro the printer, which is a quite simple task.
>
> 2c) driver based colormanagement
> In this case the driver allows to create printing queues with setups bith for a source an target profile. The user has one GUI for driver configuration and queue / colormanagement setup. CUPS does only rasterization and no color transformations.
>
> 2d) Usage of a colormanagement framework like e.g. Oyranos or colord / g-c-m
> As the profile to device match is encoded into the profile itself, the usage of Oyranos or colord/g-c-m is simplified for the printing path.
>
> I would be very glad if the GoogleSoc project could implement the
> dictType approach based on Gutenprint.
>
> As I´m a member of the ICC, I would take care, that the Gutenprint
> dictType Metadata will be registerred at the ICC.