| Summary: | Assigning Ratings using Ctrl+[1..9] assigns a color code during preview && modifies "By Date" sort order | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Jens <jens-bugs.kde.org> |
| Component: | Tags-Rating | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | metzpinguin, mf-bugs.kde.org |
| Priority: | NOR | ||
| Version: | 8.3.0 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/graphics/digikam/-/commit/6066ca8869b5b57e6cf826711cfaaa27b4d858d7 | Version Fixed In: | 8.3.0 |
| Sentry Crash Report: | |||
| Attachments: |
before assigning a rating
after assigning a rating |
||
|
Description
Jens
2024-01-05 11:41:43 UTC
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? |