[Openicc] GoSoC 2011: CPD and Color Management

[Jan-Peter Homann]

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.

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.

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:

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.

Best regards
Jan-Peter



Am 30.04.11 04:32, schrieb Robert Krawitz:
> On Fri, 29 Apr 2011 11:18:13 +0200, Jan-Peter Homann wrote:
>> Hello all,
>> I´m happy to hear that the proposal was accepted. I plan to help where I can. I read the proposal and the links provided by Till.
>> One central point to solve is the association of a driver setup with an ICC-profile. A very smart approach to this task was already discussed in the list is as following:
>> - All necessary informations to setup the driver are encoded in the profile incl. e.g.
>> - per channel ink limiting
>> - per channel calibration curves
>> - resolution
>> - rasterization
>> ...
>>
>> This allows an easy exchange of profiles between users and secures,
>> that driver setting and profile will match after the profile is
>> imported.
>>
>>   From the GUI, the profile chooser will be the center for all color
>>   relevant options.
>>
>> During profile generation we need a communication layer between the
>> driver (e.g. Gutenprint) and the profile generation software
>> (e.g. ArgyllCMS). This communication layer pulls the driver setup,
>> wich was active during printing the testchart and writes the
>> information into the profile.
>>
>> I would prefer a solution, which would be independent both from
>> drivers and profiling solutions, so that it could be
>> e.g. implemented into Oyranos or g-c-m with may be Gutenprint and
>> ArgyllCMS being the first solutions to support it. Even if the
>> profiling solution would not support it directly, such information
>> could easily integrated into every ICC-profile afterwards through
>> Oyranos or g-c-m.
>>
>> The main question for prototyping would be to find a first driver
>> developer who will be able to support the project:
>>
>> Robert:
>> Do You think Gutenprint would support such a project ?
>> If yes, what will be a timeframe for Gutenprint being able to import a complete setup with one file ?
>>
>> Anne:
>> Do you think, that the ICC automated workflow group would support the project with an outlook to be an official applied ICC tag ?
> I'd like to get a better understanding of what you have in mind.  It
> isn't clear to me what information you need that can't already be
> provided by Gutenprint using its existing API.
>


-- 
----------  Please note the new adress --------------

homann colormanagement --------- fon +49 30 611 075 18
Jan-Peter Homann ------------ mobile +49 171 54 70 358
Cotheniusstr. 3 -------- http://www.colormanagement.de
10407 Berlin -------- mailto:homann at colormanagement.de