[Openicc] Renaming an ICC profile

Max Derhak Max.Derhak at onyxgfx.com
Wed May 14 06:56:09 PDT 2014


I'm a bit concerned about using the concept of "Original Checksum" as a metadata element. 

Once established, any change of the profile without modifying this metadata field will become invisible.  In my opinion the checksum should be the checksum.  If you are changing the profile you are changing the profile.  Just like changing a filename you need to modify all references to it in order for things to be consistent.  

Additionally, what happens when someone adds the original profile again to the system, you then have two profiles with the same checksum?  Any profile can mascaraed as another profile by adding/adjust a metadata element.  Additionally, you loose the possibility to algorithmically verify that the checksum is correct - you no longer have a checksum.

Max Derhak
Principal Scientist
max.derhak at onyxgfx.com

-----Original Message-----
From: openicc [mailto:openicc-bounces at lists.freedesktop.org] On Behalf Of Richard Hughes
Sent: Wednesday, May 14, 2014 5:27 AM
To: OpenICC Liste
Subject: [Openicc] Renaming an ICC profile

Hi all,

One frequent request from users seems to be the ability to "rename" an ICC profile in the GUI. What they mean is to change the description value of user-local profiles (rather than system-installed profiles).
Allowing this does pose a few problems:

* We don't want to restrict the user to ASCII for v2 profiles
* We don't really want to change the header checksum otherwise the mapping to devices will be destroyed

I see two ways around this. For a v4 profile we can of course just use a MLUC value and store in the UTF16 values of what the user entered, but should the locale of this be the users locale (e.g. pt_BR) or the system locale (e.g. C) -- if it's the former then we probably need to store an "English" version of the profile description, although I'm not sure how that could be generated. I'm not sure if applications assume that they'll always be a non-NULL locale entry in the MLUC
(lcms2 seems to do the right thing) or if such a program would just be considered buggy.

For a v2 profile, I suppose it makes sense to use the non-standard cmsSigProfileDescriptionTagML and then use the MLUC value like above.
This means applications need to read the cmsSigProfileDescriptionTagML and if present prefer this over the cmsSigProfileDescriptionTag value.
This seems to be what Apple does in OS-X, although I think in Linux only programs using libcolord will do the fallback like this at the moment. A safer bet might be to write cmsSigProfileDescriptionTagML and then some ASCIIfied version of the description to cmsSigProfileDescriptionTag although that seems to be inviting users to report bugs about profiles they've renamed with accented chars that are not showing in things like scribus and inkscape.

For the second point, we could introduce a new metadata property, something like "OriginalChecksum" which would represent the original file checksum and use that for matching profiles to devices. This would be easily abstracted away in libcolord, so end applications wouldn't even be aware the checksum had changed, just that the "title"
had been modified.

I've not written any code yet, but I'm open for suggestions and feedback. Thanks.

Richard
_______________________________________________
openicc mailing list
openicc at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openicc




More information about the openicc mailing list