SUMMARY If only Xmp.lr.hierarchicalSubject and Xmp.dc.subject (and digiKam:TagsList) are activated for writing/reading into/from the sidecar file, it is not possible to delete the last tag. With the digiKam namespace included, all works fine. STEPS TO REPRODUCE 1. fresh digikam installation 2. add 1 dir with one jpg in it 3.Config/Metadata/Behavior: tick all information aspects and "rescan files" 4. Config/Metadata/sidecars: enable reading and writing to xmp sidecars only 5. create the tag structrure: a/1, a/b/1 6. Disable all tags, apply 7. enable only a/b/1, apply 8. disable a/b/1, apply OBSERVED RESULT A new tag /1 is created and only the dc.subject is written in the XMP sidecar EXPECTED RESULT Remove all tags from the file, dc.subject should be deleted too. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 22.10 (available in About System) KDE Plasma Version: 5.25.5 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.6 ADDITIONAL INFORMATION I open this bug only because there were other similar side effects which I could not reproduce on the test instance. The reason for even trying this is to have a bidirectional exchange of tags between digiKam and darktable.
SUMMARY Revised If only Xmp.lr.hierarchicalSubject and Xmp.dc.subject (and optionally digiKam:TagsList) are activated for writing/reading into/from the sidecar file, it is not possible to delete the last tag. With only the digiKam namespace activaded all works fine.
Exiv2 internally uses a conversion table to map XMP metadata to Exif and Iptc or vice versa. The entry "Xmp.dc.subject" is associated with "Iptc.Application2.Keywords". Therefore "Iptc.Application2.Keywords" is then written as ""Xmp.dc.subject" in the XMP file. In order not to break the behavior for other users here, they should also enable "Iptc.Application2.Keywords" in the extended metadata. Then the problem no longer occurs. https://exiv2.org/conversion.html Maik
OK, that works fine for me. Tested it and found no problems. Maybe it would be enough just to add a hint or a warning in the settings dialog.
If I only have those 3 active but when additionally enabling "read all metadata for tags" I encounter the following behavior: Tag structure as before: /a/1 /a/b/1 If I activate /a/b/1 DK creates an additional tag /1 When "read all metadata for tags" is disabled it works fine.
The behavior is correct, normally when reading tags, the first entry with tags is aborted, the list is processed from the top down. If all tags are used, "Xmp.dc.subject" will also be read, but this does not contain a tag path, just a keyword. since the "1" is present several times in the existing tag tree, a new entry is created under "/1". Otherwise the single "1" from "Xmp.dc.subject" would be mapped to an existing tag path with the "1". Maik
If there is no way to deselect the last tag, it does not seem as "correct behavior" to me. ;) I understand that the algorithm is working as programmed, but my user stories are not satisfied: As a User I want to be able to remove all tags from an image. As a User I want only the specifically created tags to be added (and I do not want the tags to be duplicated on the root level).
Git commit 915bddbe5e8c8d104bbd4abd2988b018f0bae718 by Maik Qualmann. Committed on 27/11/2022 at 13:03. Pushed by mqualmann into branch 'master'. add function to remove interacting IPTC Tags FIXED-IN: 8.0.0 M +2 -1 NEWS M +32 -0 core/libs/metadataengine/engine/metaengine_p.cpp https://invent.kde.org/graphics/digikam/commit/915bddbe5e8c8d104bbd4abd2988b018f0bae718