[Openicc] [ANNOUNCE] OpenICC Data package 1.2.0

Richard Hughes hughsient at gmail.com
Sat May 28 01:57:10 PDT 2011

On 28 May 2011 08:51, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
> The 1.2.0 is a maintenance release. ICC profile data has partitial changed
> to cover the internal ICC hash. The hash does not alter standard ICC
> identification or colorimetric data. To colour management software the
> profiles appear to be the same as in the previous release.

Except, that's not true, is it:

$ md5sum openicc-data-1.1.0/default_profiles/base/sRGB.icc

In short, I can't believe what you've done here. Last august you
blasted me with comments like:

I understand your intention for making a coherent set. However
silently ignoring the intention of the profile authors is inadequate
to reach that goal. The canonical way is to keep the profiles hash as
is or fork which is allowed with all those profiles.
These profiles have uncertain sources and are altered without notion,
they are not a solid reference for compositing and exchange.

So, I see you've added the all the profile IDs to the icc files
included in your package. I'm guessing you've used the idea from
colord and shared-color-profiles to increase the I/O performance at
cold start, given the change hit Oyranos a few days after hitting

But in adding the profile ids, you've altered all the file MD5
checksums that you care so much about, and destroyed your argument
that fixing the case of the profiles to make the GUI not suck is
unacceptable as it changes the file checksum.

So please, can you clarify. Is the file checksum hash allowed to
change in your packages? Because if they are, you might as well fix
the casing and grammar in some of the profiles, and then you're
shipping the exact same files as me already as in
shared-color-profiles. If they are not allowed to change, then you
need to revert the profile-id you've just added and go back to
shipping the old icc files.

I'm pretty sure you can't argue it both ways.


More information about the openicc mailing list