Bug 402288

Darktable stores Xmp.lr.hierarchicalSubject as Seq. This does not conform to the Adobe standard that provides a Bag. We use the capitalized alternative Xmp.lr.HierarchicalSubject as Seq. Since I can not determine at the moment which program it will use thius variant, I will not change it. Create a new entry that corresponds to the Darktable format and deactivate the default entry.

Maik

(In reply to Maik Qualmann from comment #1)
> Darktable stores Xmp.lr.hierarchicalSubject as Seq. This does not conform to
> the Adobe standard that provides a Bag. We use the capitalized alternative
> Xmp.lr.HierarchicalSubject as Seq. Since I can not determine at the moment
> which program it will use thius variant, I will not change it. Create a new
> entry that corresponds to the Darktable format and deactivate the default
> entry.
> 
> Maik

Thanks Maik for your comment,
I intend to create a new entry, but I lack precise documentation about each field of an entry. I already try to create a second entry with the same Name, but digikal cant manage them properly (see bug 402283). Which field DO match with the corresponding XMP metadata ? Are they casesensitive ?

I stumbled across the same issue yesterday. In an effort to achieve compatibility between digikam and darktable, I used Settings > Metadata > Advanced to only enable Xmp.lr.hierarchicalSubject for tags, only to then find out that my tags are deleted by a digikam->darktable->digikam roundtrip.

Then I tried the workaround suggested by you, Maik, i.e. creating a new entry that is a duplicate of Xmp.lr.hierarchicalSubject but with TAG_XMPSEQ instead of TAG_XMPBAG and enabling only that one. That seems to make the roundtrip work, but I guess you might lose tags now if they are stored in a standard-compliant way.

What darktable does, btw, is to accept both Bag and Seq when reading xmp sidecars but then to always write the sidecar back using a Seq. Wouldn't this be an option for digikam as well (reading both, saving as Bag)? I see that the functions MetaEngine::getXmpTagStringSeq and MetaEngine::getXmpTagStringBag are almost identical. Why not change them so they try to find the specified item (Bag or Seq) first but if this not found and there is only the other type, this one is read instead?

I don't have experience to judge if there would be unintended side effects. But regardless of what is conforming to the standard, I think compatibility and avoid data loss is more important.

Which digiKam version do you use? A namespace can exist multiple times since some versions. Simply create a new "Xmp.lr.hierarchicalSubject" as "TAG_XMPSEQ" and move it before the default entry. Then it first tries to read as "TAG_XMPSEQ" and then falls back to the default entry. The same when writing, both variants are written.

Maik

I was testing with the 6.2.0 Appimage. Thanks for the info that I can add the same namespace multiple times. This is certainly an improvement for my current setup. :)

When looking at the default config for Xmp.lr.hierarchicalSubject, I noticed that Xmp.lr.hierarchicalSubject is set to TAG_XMPBAG and the alternative name is Xmp.lr.HierarchicalSubject (capitalized) as TAG_XMPSEQ. From what I understand now, this looks digikam always write the non-capitalized version only (as Bag) and if not found during reading, it will try to read the capitalized version as Seq only. Considering that you wrote in comment 1 that you use the "capitalized alternative Xmp.lr.HierarchicalSubject as Seq" (which seems not the current behavior any more), doesn't that mean there is another issue and digikam might not be able to read tags from its own sidecars from older versions any more?

In any case, while I very much appreciate your comments that help me configure digikam to be usable for my workflow, I would be very happy if out-of-the-box compatibility between digikam and other applications is as high as possible. I guess this would either mean making the reading more fault tolerant or adding another default entry.

Is as good as possible out-of-the-box compatibility with darktable and other applications also something you are aiming for or is this something where I should just tune my config?

At the moment I have only the Windows version available. But see that double entries make problems that should not be. I'll watch it tonight.

Maik

If saved with OK, there are no errors, otherwise other entries can double, I will fix it. If Darktable actually reads both variants, let digiKam save it as BAG, so there are no problems in other applications. Both variants are not possible in the image metadata anyway.

Maik

@Gilles, do you know an application that uses "Xmp.lr.HierarchicalSubject" with capital letter (H)and as TAG_XMPSEQ? I think that the 2nd alternative in our advanced metadata should actually be for Darktable and the capital letter is just a mistake.

Maik

I did some digging and at least in 2010, Gilles did... ;) See bug 221460 comment 12.

To Maik comment #8

"@Gilles, do you know an application that uses "Xmp.lr.HierarchicalSubject" with capital letter (H)and as TAG_XMPSEQ? I think that the 2nd alternative in our advanced metadata should actually be for Darktable and the capital letter is just a mistake."

You right. The H capitalized is a mistake : https://www.exiv2.org/tags-xmp-lr.html

i'm sure that Exiv2 has used 'H' in the past...

But wait a minute... Exiftool use 'H'... ahaha

https://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/XMP.html#Lightroom

Gilles

Git commit 3902d36b83a3853a87f27031eae58de81cdd3a2e by Maik Qualmann.
Committed on 19/08/2019 at 19:39.
Pushed by mqualmann into branch 'master'.

fix wrong namespace container in editor after move

M  +34   -18   core/utilities/setup/metadata/advancedmetadatatab.cpp
M  +4    -0    core/utilities/setup/metadata/advancedmetadatatab.h
M  +21   -20   core/utilities/setup/metadata/namespacelistview.cpp
M  +3    -4    core/utilities/setup/metadata/namespacelistview.h

https://invent.kde.org/kde/digikam/commit/3902d36b83a3853a87f27031eae58de81cdd3a2e

Yes, Lightroom... Ok, then the best workaround is to add a new duplicate "Xmp.lr.hierarchicalSubject" entry as a sequence before the default entry.

Maik