[Openicc] [Fwd: icm profiles in debian]

[Kai-Uwe Behrmann]

Am 03.02.2013 12:05, schrieb Richard Hughes:
> On 3 February 2013 10:13, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
>> Looking at the colord package, all distributed profiles are automatically
>> generated. In parts they use copyrighted names, which implies legal
>> conflicts. That's the wrong way to do profile distribution.
>
> Can you explain how using a copyrighted name implies a legal conflict?
> I've asked about AdobeRGB before, and strictly colord should title the
> profile "Compatible with Adobe RGB (1998)" which I'll do if anyone
> from Adobe contacts me about the issue. I think it's quite obvious for
> a "consumer" looking at the profile that it's not the official Adobe
> profile.
>
>> As well for normal users it is not clear, where those generated profiles
>> come from.
>
> Sure it is, colord adds metadata to that effect:
>
> Object Path:   /org/freedesktop/ColorManager/profiles/icc_4532df47b7f58666d218ec8d842d422e
> Owner:         root
> Format:        ColorSpace..
> Title:         sRGB
> Qualifier:     RGB..
> Type:          display-device
> Colourspace:   rgb
> Gamma Table:   No
> System Wide:   Yes
> Filename:      /usr/share/color/icc/colord/sRGB.icc
> Profile ID:    icc-4532df47b7f58666d218ec8d842d422e
> Metadata:      CMF_binary=cd-create-profile
> Metadata:      CMF_version=0.1.29
> Metadata:      CMF_product=colord
> Metadata:      STANDARD_space=srgb
> Metadata:      License=CC0
> Metadata:      DATA_source=standard

The problem with such meta data is, it is nearly invisible to end users. 
No one looks at meta data when they are needed. Or let me ask 
rethorical, how could the meta data be integrated into a profile 
selection dialog. Honestly, I have no useable answere to that.

What users see at profile selection time inside a colour space 
conversion dialogs or other dialogs is the profile internal name from 
the 'desc' description tag and perhaps the file name. It is very similar 
to selecting fonts.

>> As soon as profiles are generated on the fly, like by colord during compile
>> time, their profile ID will change with each second.
>
> Sure, the ProfileID also changes if you add any metadata to the
> profile, which means you can't take advantage of new features and
> functionality. It's allegory to me is having a kernel module that has
> to use a fixed kernel ABI -- it makes it impossible to add new
> features without horrific hacks (like shipping the metadata in a
> separate file).

Just bump the version in the name. e.g. sRGB_v1.1_colord.icc ?
Of course a compile time generation would still contradict a versioned 
file name.

>> As the profile ID is
>> the typical mechanism to detect source == output profile, that is for some
>> systems a problem,
>
> Right, but we can't pretend that's going to work when we use a sRGB
> from any of the Linux profiles packages (e.g. openicc-whatever,
> colord, etc) if we send the profile to anyone using OS-X, which has
> it's own version. And we can't pretend it's going to work on Windows
> either, which also ships an unofficial version of sRGB. If the user
> wants this to work, then can manually download the official non-free
> sRGB profile from the website and use that as the default sRGB
> embedding profile.

You are right here. But how about you preparing a fixed version of a 
sRGB profile with all the stuff colord needs. We can review it here and 
can propose it to the ICC as a default profile with a proper license for 
Debian. If that does not work out we could recommend it as the OpenICC 
group including colord and Oyranos, and Argyll too(?). Perhaps we come 
to only two versions and can keep them some years.

> I think it's much more sane to just check if the profile is identical
> from the TRC and has the same matrix / LUT data, then it's the same
> profile.

lcms and Argyll flawours differ slightly. That is not so easy.


kind regards
Kai-Uwe