SUMMARY When writing a .xmp sidecar for images with a color label set, two properties are exported to the metadata: "xmp:Label" and "digikam:ColorLabel". If now an external program, not being aware of the "digikam:ColorLabel" item, changes the color label, "xmp:Label" gets updates, and "digikam:ColorLabel" remains as it was, leading to inconsistent values. On import of this inconsistent .xmp file back into digikam, the "digikam:ColorLabel" value takes precedence, and modifications of the external program get lost. Solution proposals: a) in case of inconsistency, give precedence to the more standard labels (in this case, favor "xmp:Label" over "digikam:Colorlabel"). b) (more flexible, but likely more effort): Add a configuration option to settings/Metadata/extended, allowing to configure how to deal with im- and export of color labels (similar to the configuration possibilities for ratings, comments, etc.). STEPS TO REPRODUCE 1. Import image to digikam 2. Set metadata to sidecar files only 3. Set color label to image 4. modify color label with external program --> metadata in sidecar file becomes inconsistent (xmp:label vs. digikam:ColorLabel). 5. re-read metadata in digikam OBSERVED RESULT Modification of color label with external program gets lost (digikam:ColorLabel takes precedence). EXPECTED RESULT Modification of color label from external program is respected by digikam SOFTWARE/OS VERSIONS Windows: 10 v. 1909 macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
This is more of a bug report for the external program "digikam: ColorLabel" to be set correctly. ((:-)) Color labels is a difficult topic because there is no standard and many programs define their own colors. Often digiKam cannot accept the colors from "xmp: label". Maik
Another point about digikam:colorLabel : this tag come from digiKam XMP namespace. It's used as database backup in XMP sidecar for internal use only. It's not a standard. The real shared and "standard" tag for this topic is the xmp:label. Of course both must be sync as possible. Gilles Caulier
For me it seems like the easy solution for reading color labels would be to always use "xmp:Label" if it contains useable data, and only fall back to digikam:ColorLabel if this is not the case. What do you think? Heiner
Well no : if digikam tag exists it must be taken first as contents is always decodable, if sync mechanism with standard XMP tag work as expected of course. the digiKam XMP tag is useful if a corruption appear in database. If you backup the digiKam properties in XMP, a simple re-import of items will recreate automatically the database contents. You lost nothing. Gilles Caulier
I have the feeling I miss some important information here: Currently, it seems to me like xmp:label and digikam:ColorLabel are redundant (storing the exact same information just in different formats: "Red" vs "1", "Orange" vs. "2", and so on). Hence I do not understand why digikam:ColorLabel is stored at all in the .xmp file. I also do not get the database argument of Gilles. If the information is redundant, why does it matter whether xmp:Label or digikam:ColorLabel is used to restore the database in case of any errors? Can you please help me to understand? Independent of the technical details, the behavior described in this bug report breaks my workflow. I use an external program which seems to write compatible xmp:Label values in the sidecar files. However, those values are ignored by digikam, unless I remove the "digikam:ColorLabel" information from the .xmp files. However, if I remove digikam:ColorLabel manually, digikam is updating the color labels to the xmp:Label values as expected. Thanks, Heiner
*** Bug 421693 has been marked as a duplicate of this bug. ***
Yes, Exactly, it breaks any workflow. I use 'safe' colro labels: red, yellow, green, blue and purple because those colors are available and universal in any program and are written to xmp:Label. Maybe an option to take xmp:Label first... In the meantime this command obviously fixes this problem so if you change something run it and it's done. Of course if you do much back and forth is a pain in the ass. For me it's not that bad because I catalog all my files just with metadata, I edit my pictures in Capture One and apply ratings and color labels and once they are done, I run that command and digikam pick up the right color. I only have to do it once but still, it's not desirable. Command: exiftool -r -digiKam:ColorLabel= Adjust with your preferable options
Sorry, the command is exiftool -r -ColorLabel=
Git commit 2da18137862bf6daa72a4cdc8ac6540ac2de1b37 by Maik Qualmann. Committed on 18/05/2020 at 19:17. Pushed by mqualmann into branch 'master'. add basic support for color label in the advanced metadata settings TODO: Add dialog for converting color label values. Related: bug 421693 FIXED-IN: 7.0.0 M +3 -1 NEWS M +3 -2 core/libs/metadataengine/dmetadata/dmetadata.h M +134 -57 core/libs/metadataengine/dmetadata/dmetadata_labels.cpp M +38 -0 core/libs/metadataengine/dmetadata/dmetadatasettingscontainer.cpp M +7 -3 core/libs/metadataengine/dmetadata/dmetadatasettingscontainer.h M +4 -0 core/utilities/setup/metadata/advancedmetadatatab.cpp M +13 -0 core/utilities/setup/metadata/namespaceeditdlg.cpp https://invent.kde.org/graphics/digikam/commit/2da18137862bf6daa72a4cdc8ac6540ac2de1b37