[Openicc] OpenICC GSoC 2011 ideas / driver setup to profile match

[Jan-Peter Homann]

Hello all,
A printer profile represents a driver setup. From the user experience, 
we have following workflow:
- define a driver setup
- print a testchart with "No Colormanagement" option in the print chain
- associate the printer profile with the driver setup.

During daily production, the user first chooses the driver setup he 
wants to print and then the profile matching this driver setup should 
been automatically choosed.

Do realize this, I see following possibilities:

1) Create virtual CUPS printers for every driver setup
This solution could easily be implemented with colord / GCM and Oyranos 
as they are available today
This way could also be used with every kind of driver (e.g. Gutenprint, 
drivers of printer vendors etc...)

2) Usage of cupsICC approach
The driver setups are organized in a way, that the user sees in the 
printing GUI only the selectors compatible with cupsICC definition (e.g. 
mediatype and resolution), the user has no possibility (or only with bi 
warnings !!) to change specific driver parameters.
The CMM framework uses than cupsICC to identify the matching profile for 
the driver setup

3) Making the profile the master for the driver setup
During profilecreation, all driver setup-parameters are integrated as 
metadata into the printer profile.
In the printing GUI, there is no possibility for the user to change 
driver setup parameters. He only sees a list of available profiles for 
the printer. Optional: After choosing a profile, the user sees additonal 
informations about driver setup parameters.
After choosing the profile in the printing GUI, the driver is setup 
automatically
For realizing this, we have to specify / develop
- a place for driver specific metadata in ICC profile
- a way for presenting profiles in the printing GUI
- a way for the driver to know which profile have been choosed in the 
printing GUI
- an update for the driver to extract the metadata information from the 
profile.

4) Fuzzy Match approach
During profilecreation, all driver setup-parameters are integrated as 
metadata into the printer profile.
The user chooses the driver parameters as they are presented in the 
printing GUI.
The CMM Framework compares the driver parameters with a available 
printer profiles and does a fuzzy match for the best profile.
In this workflow, the driver vendor has to be carefully,
- which driver parameters are presented to the user
- And how are internal driver parameters are organized.
- Whic driver parameters are used for the fuzzy match
E.g changing only the parameter for resolution can drastically change 
color results of the print out.
But if e.g. every resolution has his own ink limit and per channel 
linearization, the color results for differnt resolutions can (!!!) be 
made quite similar.
Please note that individual driver parameters for resolution, inklimit 
and per channel linearization must be different, for leading to similar 
color results. This is contrary to a fuzzy match approach based on all 
individual driver parameters.
A fuzzy match indeed makes sense, when it is based on calibration 
targets for a driver setup. But for doing this we need metadata, that 
specific groups of driver parameters have been setup to match a specific 
calibration target...

5) conclusion
We have quite different technical approaches to organize the matching 
process of driver setups and printer profiles. Approach 1) needs no 
programming work. Approach 2) is more a question how the driver 
paramters are grouped and presented in the printing GUI and how the 
printing GUI is supporting cupsICC.
Approach 3) could may be realized in a GSoc project, but would may need 
two mentors for a) ICC-profile and CMM framework aspects and b) the 
driver aspects to extract the metadata through the CMM framework. 
Approach 4) needs parts of approach 3) with addition of integration of 
calibration metadata in the process.






Am 28.03.11 11:22, schrieb Richard Hughes:
> On 28 March 2011 09:54, Kai-Uwe Behrmann<ku.b at gmx.de>  wrote:
>> The above proposal completely misses the driver part.
> What's a "driver part"?
>
>> We have notoriously mentioned here on list, that a device only ID is bad
>> usability.
> I'm not sure how you can relate the concept of usability to a low
> level textual descriptor. Can you explain what you mean?
>
> Usability is describing the success of how the user is executing
> several high-level use-cases using the GUI tools. Whether the tools
> are using device-ids, or some fuzzy matching has nothing to do with
> usability, it's just a implementation detail.
>
> The benefit of using an ID to map a device to a profile is that we can
> say "colord has mapped *this* profile to *this* device for reason
> *foo* and then when using oyranos we get the same device->profile
> mapping appear in the dialog. It might be that oyranos and colord
> differ too much in the internal implementation to make this possible,
> which would be a shame.
>
>> Things like the Gutenprint and EDID colour related options should
>> be part of the ICC device profile association.
> I think the EDID data belongs as metadata on the profile, and perhaps
> as well even on the device itself (again, as metadata) for the
> purposes of matching.
>
> Could you perhaps write a short specification document explaining how
> the oyranos device to profile matching is done so we can find some
> common ground?
>
> Thanks,
>
> Richard
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
>


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