Summary: | Digikam won't remove tags set by Windows Explorer | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | Sebas <djsebas> |
Component: | Metadata-Engine | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | caulier.gilles, metzpinguin |
Priority: | NOR | ||
Version: | 5.5.0 | ||
Target Milestone: | --- | ||
Platform: | Microsoft Windows | ||
OS: | Microsoft Windows | ||
Latest Commit: | Version Fixed In: | 6.0.0 |
Description
Sebas
2017-05-16 22:04:19 UTC
Please try the pre-release bundle digiKam-5.6.0 from here: https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM I think this bug is allready fixed. Maik Thank you for the link. I tried 5.6.0 and it does not seem to be fixed. Which Windows Explorer tags exactly? Maybe a test image with these tags? Maik I did some deeper research. The field where Windows Explorer saves the tag has the name "XPKeywords" according to IrfanView. DigiKam has a metadata tag entry for this, but searching a bit further brought this up: http://dev.exiv2.org/boards/3/topics/530 So I guess that is the problem here? Well, digiKam has already all rules to manage XPKeyworks tags. Look code here : https://cgit.kde.org/digikam.git/tree/libs/dmetadata/dmetadata.cpp#n1344 https://cgit.kde.org/digikam.git/tree/libs/dmetadata/dmetadatasettingscontainer.cpp#n268 This want mean that your Setup/Metadata/Advanced config panel must be tune properly about XPKeyworks. Gilles Caulier There is a default tag rule, this one: Metadata Subspace: EXIF Name: Exif.Image.XPKeywords Special Options: NO_OPTS Alternative name: Alternative special options: NO_OPTS Separator: ; Set Tags Path: [V] The rule is enabled. I used the 'Reset to Default' button when checking for the second time. I can not add a rule for XPKeywords because when adding a rule, the only option allowed for 'Metadata Subpspace' is XMP. This issue is resolved with digiKam-6.0.0. If all metadata write settings are enabled, re-reading the metadata cleans up the database beforehand. I close this bug now. Maik |