Bug 481180 - digikam incorrectly reads metadata field "Subject" when "HierarchicalSubject" is also present
Summary: digikam incorrectly reads metadata field "Subject" when "HierarchicalSubject"...
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Metadata-Xmp (show other bugs)
Version: 8.1.0
Platform: Debian testing Linux
: NOR minor
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-02-10 18:53 UTC by fales
Modified: 2024-02-11 10:22 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 8.3.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description fales 2024-02-10 18:53:46 UTC
SUMMARY
Keywords present in "Subject" are ignored if they are part of any "HierarchicalSubject" keyword and they are not the last part of  "HierarchicalSubject" keyword.

STEPS TO REPRODUCE
1. Prepare a picture with the following metadata fields (all other tag related metadata empty):
 - Subject: France, Nord, Lille
 - HierarchicalSubject: places|France|Nord|Lille 
This can be done e.g. by command:
 - exiftool -Subject="France, Nord, Lille" -HierarchicalSubject="places|France|Nord|Lille" image.jpg
in my case the tags are generated by darktable.
2. Add the picture into digikam database and read the metadata.

OBSERVED RESULT
Only the last level of the tag "places/France/Nord/Lille" is attached to the picture. Hence, the picture cannot be found by searching for "France" or "Nord", it can only be found by searching for "Lille".

EXPECTED RESULT
Either both middle levels ("France", "Nord") of the tag "places/France/Nord/Lille" attached to the picture (preferably) or non-hierarchical tags "France" and "Nord" attached to the picture.

ADDITIONAL INFORMATION
If the field "Subject" were to contain also an additional tag, let's say "panorama" (while "HierarchicalSubject" being the same), the tag would also be attached to the picture. There is no reason to ignore the tags ("France", "Nord") from the example. Moreover, when digikam itself writes the read metadata (only the last level of tag "places/France/Nord/Lille" attached), the result differs:
 - Subject: Lille
 - HierarchicalSubject: places|France|Nord|Lille
Notice that only "Lille" is in the "Subject".

I don't see this topic in the release notes for digikam 8.2 (no idea about 8.3).

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Debian GNU/Linux 12
KDE Plasma Version: 5.27.9
KDE Frameworks Version: 5.107.0
Qt Version: 5.15.10
Comment 1 Maik Qualmann 2024-02-11 07:51:02 UTC
This is not a bug. Check out the advanced metadata settings:

https://docs.digikam.org/en/setup_application/metadata_settings.html#advanced-settings

Here you can specify the order in which digiKam finds the metadata in images; the list is processed from top to bottom. At the first entry where valid values are found, the process is aborted and this one is used. You can set the order yourself, you can also see that xmp.lr.hierarchicalSubject is before xmp.dc.subject in the list, therefore tags in xmp.dc.subject are ignored. So if you have metadata in images that are out of sync, you can enable the "Read all metadata for tags" option. Now digiKam will read and mix all metadata fields for tags. Then you have your desired result.

Maik
Comment 2 fales 2024-02-11 09:38:37 UTC
Dear Maik,

I had been aware of the advanced metadata settings and I had tried to change the order of the fields to resolve the issue. However, I did not know that by default digikam only reads the first valid one and I did not noticed the settings "Read All Metadata For Tags" which resolves the issue! (While I tested the issue on digikam 8.1 in order not to report something old, my main photo collection is actually under digikam 7.1 and this option was not present in this version.) 

Thank you for your time and for pointing me to the solution.

Fales
Comment 3 Maik Qualmann 2024-02-11 10:22:45 UTC
The option to read all metadata tags was available for the first time with digiKam-7.5.0 through Bug 447503.

Maik