Problem adding entries to XMP-IPTCExit::ArtworkOrObject using flattened tags

[Mac2]

Yes, I believe that's what Phil was saying above when he corrected me above in this post.  The tag ID will be the Structure name+Structure element, so as you say, remove the structure name to get the element.

Yes, that's simple enough, if it is consistent and reliable.

Looking at the XML output for a file, we get

Code Select Expand

<XMP-iptcExt:ArtworkCreator>
 <rdf:Description et:id='ArtworkOrObjectAOCreator' et:table='XMP::iptcExt'>
  <et:prt>
    <rdf:Bag>
      <rdf:li>C1</rdf:li>
    </rdf:Bag>
  </et:prt>
 </rdf:Description>
</XMP-iptcExt:ArtworkCreator>
...
but the structured tag output uses

Code Select Expand

<XMP-iptcExt:AOCreator>
  <rdf:Bag>
    <rdf:li>C1</rdf:li>
   </rdf:Bag>
 </XMP-iptcExt:AOCreator>

When we have the new struct attribute for tags in a future ExifTool version (I have already implemented this in my parser and the database), we can at least tell for each flattened tag how to produce the tag name required for writing the tag by removing the parent's id from the flattened tag's id.

[StarGeek]

Really looking forward to how you implement this in IMatch.

[Mac2]

Really looking forward to how you implement this in IMatch.

This is not something that will affect many users (It came up for Artwork recently - one user).
But I prefer to make this work in general. The current method of just separating multiple elements via ; in the MD panel failed for this structure, which is why this came up.

If I make it work for multiple entries separated via ; this will be a win.
The plan is when the user modifies one or more elements of a structured tag to always write the full tag. With the new struct attribute the code can find all tags for the structure and produce the optimal arguments for the args file. I don't think partial updates will work, according to the info on https://exiftool.org/struct.html

The next step would be a generic multi-value nested structure editor, but these are a) quite a pain to implement and b) not really needed or useful for the majority of users. This would probably be a nice to have, 'rainy afternoons for two weeks' project.

[Mac2]

Can this be a problem?

The combination of group id and tag id is not always unique.
There are 277 cases by my counts.

For example the group DNG::AdobeData contains 91 tags with the id 'MakN'. The tags have different 'tag' Attributes, though. Exif::Main contains 91 tags with the id 37500 but different values in 'tag'.
There are also some (rare) cases where group id, tag id and tag are identical and only the index is different.

Only the combination of (group id, tag id, tag name, index) is truly unique.

Looking up a struct members parent tag only by group id and tag id (from the new struct attribute) is thus not necessarily unambiguous. I don't know yet if this affects any structured tags. Seems more like maker notes and other obscure tags.

Is it save to assume that I can always lookup a parent tag using

group: same as tag
id: value delivered by ExifTool in the struct member
tag: same as id
index: 0

For example, for tag id 'ArtworkOrObjectAOTitle' with struct = 'ArtworkOrObject', I find the tag's struct parent with

group: XMP::iptcExt
id: ArtworkOrObject
tag: ArtworkOrObject
index: 0

[Phil Harvey]

The non-unique entries (tags with an "index") are ones where the actual tag is different depending on context.  This does not happen for any XMP tag, and structures are only implemented for XMP.

- Phil

[Mac2]

Thanks, Phil!

[Mac2]

I have planned for the "struct" change introduced in the 12.50 and simulated it using the ArtworkOrObject tag set.
Today I finally could make some time to update to ExifTool 12.51 and the new struct attribute works just great.
My database now lists 243 structs with 2,375 elements.

Thank you again!
Knowing the parent tag for structures makes things a lot easier!

[Phil Harvey]

Great!