Since upgrading to 2024-01-01 (also in 2024-01-03 appimage), when I preview an image and then press Ctrl-1..5 to assign stars / ratings, this automatically also assings a color to the image and gives it a colored border. This did not happen before. Also, when assigning a rating or color, sorting images "By Date" seems to use the sidecar XML filesystem modification date (?) and not the original image date (EXIF, IPTC or filessystem), because the images are resorted upon assigning ratings when choosing "Sort by Date". I let Digikam write metadata only in sidecar files, the originals are never touched. This also did not happen with previews (start of December) appimage snapshots. The hotkeys are default: Ctrl-NUM for rating and Ctrl-Alt-NUM for color codes. STEPS TO REPRODUCE 1. Set digikam to write only to metadata sidecar files, and to sort by image date 2. Tag some images during preview 3. Watch color codes being assigned and sort order being modified SOFTWARE/OS VERSIONS: KDE Neon 22.04, with 2024-01-03 Digikam appimage
Please note the digiKam-8.3.0 version as a test version, use the stable AppImage of digiKam-8.2.0. Due to a Qt6 bug we had to switch internally to UTC time. This bug is closed for Qt-6.6.2. We may then be able to switch back. If a color lab appears, it would be present in the metadata. Check the metadata for it. It has been this way for a long time that the modification time is used by the sidecar, as we need to detect external changes to the sidecar or image. Maik
Another more detailed explanation of the modification date. Until December, which modification date we used still depended on the option to update the timestamp. But that was a bug and led to incorrect detection for users who made external changes. We write the latest date into the database, either from the picture or from the sidecar. This allows us to detect external changes. Maik
Please send an image + sidecar that has a color label so that we can identify the metadata that creates the color label. Maik
Created attachment 164722 [details] before assigning a rating
Created attachment 164723 [details] after assigning a rating
Here
Well without the image, it's not very helpful. After the rating, this entry appears: photoshop:Urgency="4" This is a color label that certainly comes from the image itself. If you don't want photoshop:Urgency to be recognized as a color label, deactivate it in the advanced metadata settings (simply uncheck the entry) Maik
Git commit 6066ca8869b5b57e6cf826711cfaaa27b4d858d7 by Maik Qualmann. Committed on 07/01/2024 at 09:53. Pushed by mqualmann into branch 'master'. apply file timestamp update option to sidecars too FIXED-IN: 8.3.0 M +1 -1 NEWS M +38 -75 core/libs/metadataengine/engine/metaengine_p.cpp M +5 -2 core/libs/metadataengine/engine/metaengine_p.h https://invent.kde.org/graphics/digikam/-/commit/6066ca8869b5b57e6cf826711cfaaa27b4d858d7
Another note about Xmp.photoshop.Urgency, this interacts with Iptc.Application2.Urgency in XMP files. Check out the conversion table: https://exiv2.org/conversion.html This conversion is used to map certain Exif/IPTC metadata to XMP. Maik
Thank you for the mtime patch! I use the preview versions exactly for this purpose, to be able to report bugs. I can send you an image by private email if this is OK, I just don't want to attach it to a public bug report. However, I don't actually think the images themselves are relevant. I can assure you the images I import had no "Photoshop Urgency" attribute set when imported, they come directly from the camera and I changed nothing on the camera, no firmware update or settings, in the last year. I am pretty convinced this appeared after upgrading Digikam. I just did a "bisect" of my collection to find when this "Urgency" tag started appearing. This tag was not applied when rating photos using this appimage on 2023-09-28: -rwxrw-r-- 1 jens jens 250725568 Sep 16 22:56 digiKam-8.2.0-20230916T093515-x86-64_da62242c9f77e794a78c031a8248480c.appimage The tag *was* applied when rating photos by the same camera using this appimage on 2023-12-19: -rwxrw-r-- 1 jens jens 255956160 Okt 11 22:24 digiKam-8.2.0-20231007T150049-x86-64_8b40e8da45c132f84a7c0629766a4c64.appimage ... and all later versions. In between 2023-09-28 and 2023-12-19, I haven't yet rated or otherwise touched any of my imported images and none of them have this Urgency tag. So I suspect something happened between these two appimage versions. What could this be?
You are welcome to send me an image before a rating has been set. Maik
Ok, cause found, we added Iptc.Application2.Urgency as a possible rating metadata entry. This then leads through the XMP mapping to Xmp.photoshop.Urgency, which is a color label. Remove the check for Iptc.Application2.Urgency in the advanced metadata settings. Maik
We have already reverted this with bug 467713. So you just have to reset the rating section to the default settings in the advanced metadata settings. If you have not made any special changes, it is best to load the "digikam.dkamp" profile to be up to date. Maik
Great, that does it. Thank you for tracking this down!
I've been affected by this bug, have since upgraded to 8.5.0 and I'm still seeing color labels getting assigned after setting a rating for some files. That is, even after resetting the Advanced Metadata to defaults and loading the digikam.dkamp profile (which resets everything anyway, I presume?). From sampling a few files, it looks like only the affected ones have an Xmp.Photoshop.Urgency label, which I've never purposely set for these files (same as Jens). Do I understand this bug correctly, in that it has effectively "poisoned" my collection with these labels? Will I need to manually purge them from all my sidecars in order to actually prevent this problem from reoccurring? If so, is there are way in digikam to do this?