Darktable Tags (changed, applied styles and filetype) are written in the wrong section in XMP

[rekcodocker]

Describe the bug

Since version 5, DT is writing tags in these two sections:

   <dc:subject>
    <rdf:Bag>
     <rdf:li>1. Develop Filmic</rdf:li>
     <rdf:li>changed</rdf:li>
     <rdf:li>rw2</rdf:li>
    </rdf:Bag>
   </dc:subject>
   <lr:hierarchicalSubject>
    <rdf:Bag>
     <rdf:li>darktable|changed</rdf:li>
     <rdf:li>darktable|format|rw2</rdf:li>
     <rdf:li>darktable|style|1. Develop Filmic</rdf:li>
    </rdf:Bag>
   </lr:hierarchicalSubject>

(emphasis mine)

The problem is: dc:subject and lr:hierarchical subject are used for user-tagging. Tags by me.
I apply tags to photos in another program (Digikam) and this is the section where they are stored.

The edit-information from DT now:

• shows in Digikam, mixed in with the subject-tags
• when exported, shows up in viewer-software, mixed in with the subject-tags

I think these tags should not be in this section at all. They are not 'subjects'.

Steps to reproduce

Open an image file.
Make some modifications. Apply a style.
Close DT.
Open the XMP file and see that there are now tags added to the subject and LR-hierarchical subject sections.

Expected behavior

Put this editing-information in another section of the XMP file, not in subject or LR:hierarchical subject.

Logfile | Screenshot | Screencast

No response

Commit

No response

Where did you obtain darktable from?

downloaded from www.darktable.org

darktable version

5.0

What OS are you using?

Linux

What is the version of your OS?

Linux Mint

Describe your system?

Laptop Intel based

Are you using OpenCL GPU in darktable?

Yes

If yes, what is the GPU card and driver?

Intel

Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip

No response

[wpferguson]

The problem is: dc:subject and lr:hierarchical subject are used for user-tagging. Tags by me.

Where is this defined? Is there a reference document or specification somewhere?

Can't digikam filter tags?

See #18154.

[rekcodocker]

Yes, there is a definition. XMP is defined in the ISO standard ISO 16684-2:2014.

From that document:

Purpose of the dc:subject Field
Field Name: dc:subject
Definition: A list of keywords or tags describing the content of the resource.
Type: Ordered array (list) of text values.
Use Case: Improves discoverability of the resource by associating it with searchable terms or thematic keywords.

'describing the content' and 'improve discoverability' - so it is not a section where proprietary editing-information or use of styles (which can be arbitrarily named) should end up.

Many other programs use this 'subject' section to display what the photo is about. It is not just that digikam should filter tags that Darktable suddenly decided to put there: This field is also used by multiple image viewers, Immich, Nextcloud, ACDC and many others. It is really interfering with their use.

This information is Darktable specifc, and not interesting for any other software and it interferes with them.

[wpferguson]

So, where should they go....

[rekcodocker]

The section

<darktable:history>
    <rdf:Seq>
     <rdf:li> 

already exists.

Option 1: put them in there, dedicated name and all. If the style can be found, you're golden.
Option 2: Not at all. Just add the actual history and not the name of the style (just the operations) or type of the rawfile (that's known already)
Option 3: Close to, next to or under darktable:history, for example a new one darktable:styleinfo

[wpferguson]

history is the history stack, and processed to restore the history. If we start messing with that, we can corrupt all image processing on import.

There are more darktable tags than just styles, that was an example. For instance there are darktable|group and darktable|group_leader to fix #16827.

After thinking, probably just darktable:tags.

What about lr:hierarchicalSubject. Do you use that?

   <lr:hierarchicalSubject>
    <rdf:Bag>
     <rdf:li>darktable|format|cr2</rdf:li>
     <rdf:li>darktable|group|277a1dad-0734-4718-8ff0-f621be63b06f</rdf:li>
    </rdf:Bag>
   </lr:hierarchicalSubject>

[rekcodocker]

history is the history stack, and processed to restore the history. If we start messing with that, we can corrupt all image processing on import.

Just meant it as an example. Better not mess with it then.

Again, history works fine. I don't know what problem is solved by storing the name of a style that only exists on my PC.
It means it has no value on someone elses PC.

There are more darktable tags than just styles, that was an example. For instance there are darktable|group and darktable|group_leader to fix #16827.

After thinking, probably just darktable:tags.

Sounds like a good idea.
The tags we are talking about are (1) 100% Darktable specific and (2) very often user- or even PC specific.
Any Darktable-unique section is fine.

What about lr:hierarchicalSubject. Do you use that?

I think it is short for "LightRoom: hierachicalSubject".
As far as I know, DT also reads or writes the subject in that field. I do know DigiKam views it as a subject-field.
I would not use any existing generic (non DT-specific) field to store Darktable-specific information.

[revifr]

From what I can see, the two fields mentioned are consistent. So no bug there. Darktable wants to add those processing items as keywords, that may not be ideal, but it's not a bug, either, imo.

What I do find less than ideal is that darktable adds tags in the xmp in a way that will pollute the tag hierarchy in another program (after all, one use for sidecars is exchange of metadata between programs).

note for @rekcodocker : you might want to check the order in which digikam looks for keyword tags in the sidecars. I have Xmp.digikam.tagslist as the first item in those for both read and write, so I do not get the darktable-specific keywords transferred (but that means you won't transfer keywords from darktable to digikam at all)