[Openicc] ICC meta tag in device profiles

Kai-Uwe Behrmann ku.b at gmx.de
Wed Oct 27 01:40:16 PDT 2010


Am 27.10.10, 08:54 +0100 schrieb Richard Hughes:
> On 27 October 2010 08:13, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
>> Oyranos and KDE's kolor-manager are now able to understand device
>> capabilities inside ICC profiles through the meta tag. It complies with

>> These key/value pairs are as well stored inside the Oyranos DB. The profiles
>> are shown in kolor-manager for a given device on top of all other assignable
>> ICC profiles. This priorisation shall help users to first select ICC profile
>> which fit to a given device.
>
> Sounds very similar to gnome-color-manager -- i.e. the mapping is
> stored in device-profiles.conf [1] -- and I think it makes sense to
> standardize at least a few common keys.

If you reread, you might see that the device and driver information is 
already inside the ICC profile, which is the matter of the article.

I would not go with underscore which can easily collide with vendor 
strings. As well I disagree with many false statements on your side. 
Or can this page just be called biased writing?

For standardising EDID strings in the meta tag see below.

>> I am not shure if kolor-manager is the best place to embedd
>> device and driver informations into a ICC profile. As kolor-manager has few
>> capabilities to change driver informations. However the association of a ICC
>> profile to a colour device might appear intuitive and embedding this
>> information into a ICC profile logical.
>
> GCM can generate profiles (either from the EDID, using the hardware
> itself, or using argyllcms) so embedding extra data isn't really hard
> to do at generation time as we're already mapped to a device. I'm not
> sure it makes sense to embed user-preference data, i.e. "make this
> profile default for this device".

I wrote about device and driver information to embedded into the ICC 
profile.

The architecture with Oyranos and kolor-manager is like this:
* module detect devices - collect informations, e.g. from EDID
* assign ICC to device - store the above infos in the Oyranos DB together
   with a ICC profile inside kolor-manager
* assign device to ICC - store the above infos in the ICC profile
   itself, where to do best?
* kolor-manger - show ICC profiles with device information on top of
   others

>> I currently think, embedding makes most sense to administrate and remember a
>> association of ICC profiles with a device. So I am not shure if the meta tag
>> is the right thing to let end users fiddle with.
>
> No, in my opinion the metadata makes a lot of sense to embed things
> like the generated md5 hash of the edid, but not the actual mapping
> data. At the moment, edid-generated profiles have the edid md5 in the
> filename, which GCM uses to recognize them as generated, but this is a
> hack.

To answere your new question of what to embedd, it should be standardised 
as stated below. But the question was about where to embedd.

>> The key/values of libXcm can be formally published and explained to allow
>> vendors or advanced users to generate ICC profiles fitting certain devices
>> for distribution.

I mentioned libXcm as nice place to share common keys and deliver 
values originating from EDID. These keys and allowed values can be 
documented to deliver meaningful data for the meta tag. Vendors have then 
a relative independent means to prepare and verify their ICC profiles will 
be easily assignable.

> For me, I need to wait until lcms2 supports the dict type as I'm not
> doing the ICC decoding in GCM internally anymore. Marti, what are your
> plans for adding support for the dict type?

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


> [1] http://live.gnome.org/GnomeColorManager#Mapping_the_device_to_the_profile



More information about the openicc mailing list