[Openicc] Fwd: Settings bundles (Robert Krawitz, Edmund Ronald)

[Kai-Uwe Behrmann]

Am 17.02.11, 08:05 -0500 schrieb Robert Krawitz:
> On Thu, 17 Feb 2011 08:30:54 +0100 (MET), Kai-Uwe Behrmann wrote:
>> Am 16.02.11, 20:37 -0500 schrieb Robert Krawitz:
>>> On Wed, 16 Feb 2011 15:23:24 +1100, Graeme Gill wrote:
>>>> edmund ronald wrote:
>>>>> To coordinate the system color there will be some sort of central
>>>>> registry which associates color behavior (ICC profiles) for a given
>>>>> display or printer/media combination, and provides the user interface
>>>>> for modifying these associations when necessary. So Gutenprint needs
>>>>> to provide an interface to this color registry.
>>>>
>>>> You mean Gutenprint needs to interface to this library, don't you ?
>>>> The library should provide it's own (programmatic) API,
>>>> and ideally the Operating environment (OS or Desktop) should
>>>> provide a user interface to the library so that users can see
>>>> what's going on, and organize their profiles. Gutenprint would
>>>> also use this library to figure out what profile to use.
>>>
>>> Would it be Gutenprint, or CUPS, doing this?
>>
>> Any party in the process, which would then irrvocably set the
>> OutputIntent for the PDF/X file.
>
> Gutenprint never sees the PDF file; it gets CUPS raster.

As long as Gutenprint does not see any target profile, it is save to not 
colour convert inside Gutenprint through a ICC profile. Otherwise we can 
expect lots of smart errors to appear. The print system must rely on 
Gutenprint to accept prematched input as well as native colours for 
calibration. The prematching can happen anywhere in the chain down to the 
ICC enabled pdftoraster filter, which means Ghostscript/Poppler.

I am assuming here that the pdftoraster can produce DeviceCMYK/DeviceN 
input for Gutenprint.

>>>>> For the printer, inking settings and ICC profiles are indissociable. A
>>>>> profile is only valid under the conditions it was made.  At this point
>>>>> we have concluded that serializing the inking settings and exporting
>>>>> them to the system profile registry is the way to go.
>>>>
>>>> Not correct. The practicalities (that there are too many
>>>> combinations of printers, inks, media and settings) mean that often
>>>> it is better to use a not-perfect matching profile rather than no
>>>> profile at all, for similar media and/or settings.
>>>>
>>>> Add in calibration, and it's even less correct. You can get very
>>>> reasonable results in many situations by using the a single profile
>>>> with multiple media/setting specific calibration files.
>>>
>>> So we need to come up with algorithms to do a fuzzy match.  Do you
>>> have any thoughts on what that would be?
>>
>> Oyranos does a fuzzy match with the ICC meta tag, its device profile
>> DB or sources like PPD key/values. It would work the same for the
>> Gutenprint exported key/values.
>>
>> The matching algorithm uses a rank map per device class. This means
>> for CUPS it looks different than for Xorg. This rank map tells about
>> every key to add or substract a certain value in a certain
>> condition. Supported rank values go into the categories "not found",
>> "found and matches", "found and no match".
>
> The details of the fuzzy match are what matter here.

You like a more detailed description?
I will describe how the matching works at the moment in Oyranos.

The rank map has a static part, which might further be filled by the PPD 
"ColorKeyWords" keys.

The actual Oyranos CUPS modules static rank map is the following:
         rank_map[#]: "key"  match,none_match,not_found
         rank_map[0]: "device_name"  2,-1,0
         rank_map[1]: "profile_name"  0,0,0
         rank_map[2]: "manufacturer"  1,-1,0
         rank_map[3]: "model"  5,-5,0
         rank_map[4]: "serial"  10,-2,0
         rank_map[5]: "host"  1,0,0
         rank_map[6]: "system_port"  2,0,0

A rank map is unique to each device class in order to allow for a 
comparision of the resulting rank numbers.

For the ColorKeyWords from the PPD or any other source, I can imagine 
1,-1,0 would be good to start with. They are merged with the static rank 
map.

The above keys can be used to identify the device and driver versions and 
for comparision with a list of given dictionaries.

In more detail:
The argorithm computes a rank number by comparing a given 
device+driver/print_job key/values with a given ICC profile or DB 
dictionary, which has a similiar key set. To calculate the rank number the 
algorigthm needs the above mentioned rank map.

Typical one given key set is compared to a several other key sets. That 
can be to used to select one ICC for a given device, or search which 
device could be used with a given ICC profile.

During the rank number computation is a key from one key set searched 
in an other key set. If the key is found and the values match the "match" 
number from the rank map is added to the initially zero rank value.
If the key is found but the values do not match, the rank map is queried 
for "none_match" and that value will be added to the rank number.
The "not_found" rank map entry will be used if the key could not be found.

After that computation each key set will have its rank value, which is 
only valid related to the compared key set. That rank value can be used 
to sort ICC profiles in a profile selection dialog or simply use the best 
match for the device.


To allow for different values in a key, the values can contain a comma ',' 
separated list of single values. That allowes for, e.g. 
"Epson7800,Epson4800,Epson3800" each to be a accepted model in a according 
key.

Keys and values are all lower case before comparision can happen.


What is not well throught out is how to include non related keys. Maybe 
a additional key can be included in a key set, which works like the 
"ColorKeyWord". That would be handy to transport additional meta data that 
can reside in key which are not noted in "ColorKeyWord".


I hope you get the idea.

kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org