Fields across groups and families

[blue-j]

A field like:

Code Select Expand

xmp:xmp-plus:copyrightownerid

also overlaps with

Code Select Expand

xmp:xmp-iptcext or

Code Select Expand

xmp:xmp-iptccore presumably.

When extracting with Exiftool, is there a way to get it to report all mappings?  is it the "-a" switch?  my initial experiment with that failed.

Thanks in advance!  : )

[StarGeek]

The -a (-duplicates) option will display all tags whe there are duplicate names, but in your example, there is no overlap.  In the case of the XMP-plus tag, it is named CopyrightOwnerID.  It's a flattened tag, part of the CopyrightOwner structure (see Structured Information) and it is shortened from the full name of CopyrightOwnerCopyrightOwnerID (see Plus tags).

The XMP-iptcExt tag is called ArtworkCopyrightOwnerID, also a flattened structure tag from the ArtworkOrObjectDetails Struct and shortened from ArtworkOrObjectAOCurrentCopyrightOwnerId.

I can't find a CopyrightOwnerID tag for the XMP-iptcCore group, but the one mentioned in the IPTC standard is the XMP-iptcExt:ArtworkCopyrightOwnerID one.

IMO, the best command for extracting is the one mentioned in FAQ #3.  It will show tag names, not descriptions, all tags even if there are duplicate names, and will give the group name to separate the duplicates.

[blue-j]

You're so kind to share this information!  I sincerely appreciate it.  Thanks so much!

We coded the -a switch in our pipeline but I can't see a difference yet anywhere. Can you give me an example of a duplicate field I should be seeing?  (We focus on photo metadata and support all major group/families).

- J

[StarGeek]

You won't see obvious differences without adding the -G (-groupNames) option.  It would just repeat the same tag name. 

Some examples you would see would be
IPTC:Headline/XMP:Headline
IPTC:City/XMP:City
IPTC:DateCreated/XMP:DateCreated
EXIF:DateTimeOriginal/XMP:DateTimeOriginal
EXIF:CreateDate/XMP:CreateDate
GPS:GPSLongitude/XMP:GPSLongitude
GPS:GPSLatitude/XMP:GPSLatitude
GPS:GPSAltitude/XMP:GPSAltitude

The EXIF:CreateDate is technically DateTimeDigitized according to the EXIF spec, but for exiftool it was renamed to match the XMP tag to make it easier to copy.

The GPS tags can be problematic, as the EXIF/GPS ones don't include the directional reference (it's in a separate tag) but the XMP do. So for example, the coordinate 40.6892, -74.0445 would show up like this, with GPSLongitude displayed without the negative sign.

Code Select Expand

[GPS]           GPSLatitudeRef                  : N
[GPS]           GPSLatitude                     : 40.6892
[GPS]           GPSLongitudeRef                 : W
[GPS]           GPSLongitude                    : 74.0445

[XMP-exif]      GPSLatitude                     : 40.6892
[XMP-exif]      GPSLongitude                    : -74.0445

There are more, but they are usually a bit more obscure.  For example, Keywords can be an IPTC tag (most common), an XMP-acdsee tag (lots of duplicate names in that group), an XMP-pdf tag, an XMP-prism tag, and an XMP-xmp tag.

[blue-j]

Your generosity is sincerely appreciated!  I will check for these.  : )

Warm thanks,

- J

[blue-j]

OK, I think I am getting closer to understanding.  An example will help.  IPTC has declared that photoshop:city is a valid legacy field that is part of the IPTC Core.

https://iptc.org/std/photometadata/specification/IPTC-PhotoMetadata#city-legacy

ExifTool will not show this relationship, correct?  It will only extract it as photoshop:city or xmp:xmp-photoshop:city and not inform the user that fields from different namespaces are part of a broader spec? So we will not see a duplicate entry xmp:xmp-iptccore:city come from ET?  You only report/extract the base identity?  So, xmp:xmp-iptccore:city is not valid?  Is there any other means by which to associate fields from other namespaces?

Thanks in advance for your time in considering my question.

- J

[blue-j]

There are many other examples, like PLUS fields and IPTC Extension, etc., in case my example is nettlesome and an outlier.  - J

[StarGeek]

OK, I think I am getting closer to understanding.  An example will help.  IPTC has declared that photoshop:city is a valid legacy field that is part of the IPTC Core.

"photoshop:city" is what the IPTC spec calls it.  For exiftool, it is XMP-photoshop:City.  You have to be careful not to assume that what other sites or programs call a field that it will be the same in Exiftool.  Also, you have to make sure not to confuse IPTC Core schema as shown in your link with the XMP-iptcCore tags.  Not all of the IPTC Core schema tags are part of the XMP-iptcCore group.

Also, to complicate things, the XMP-photoshop:City is a "Legacy" tag in that it is being replaced by the Location created and Location Shown in the Image structured tags, which both use the Location Structure as sub-tags.  And that becomes another example of not confusing Schema vs Tags.  The City entry there only shows "Iptc4xmpExt:City", but obviously more info is needed as to whether it is Location Created or Shown.  And then, since they are structured data, exiftool gives the option to write those as Flattened tags (rather than having to input the entire structure at once), using the names LocationCreatedCity and LocationShownCity.  See Structured Information for more details on structured tags. 

Heh, I've probably made everything even more confusing.  Side note, I read somewhere that one of the reasons for Location structured tags is the fact that the original specs never made it clear whether the older tags where supposed to mean the location where the image was taken or the location where the image was shown.  I could be wrong about that though.

ExifTool will not show this relationship, correct?

Correct, exiftool will show only the information you ask for.  And you need to clarify what you want in cases there are duplicates from different groups.  I believe that there's no guarantee as to which tag gets shown when there are duplicates, as I think it depends upon the order the tags are in the file.  I'm not sure but Composite tags may override as they are the last created.  At least that's what seems to happen with GPS tags.  Phil would be able to clarify further.

It will only extract it as photoshop:city or xmp:xmp-photoshop:city and not inform the user that fields from different namespaces are part of a broader spec? So we will not see a duplicate entry xmp:xmp-iptccore:city come from ET?  You only report/extract the base identity?  So, xmp:xmp-iptccore:city is not valid?  Is there any other means by which to associate fields from other namespaces?

It all depends upon the options used as to what is displayed, but if you ask for xmp-photoshop:City, you will only get that tag, not any other tags with similar names.  But you need to check the tag names page for what the actual tags are.  xmp-photoshop:City is the only tag that actually exists in your last paragraph.

I should also say that it's usually best to keep the tag names simple in order to avoid possible problems.  For example, while xmp:xmp-photoshop:city will work, it's overly detailed.  By default exiftool will write tags to the more common location and will avoid the more obscure ones.  For example, the ACDSee tags.  Trying to be specific when your not familiar with the tags can lead to problems.  EXIF tags are a big example.  The EXIF groups are named IFD0, IFD1, InteropIFD, ExifIFD, and several other names.  If you try to be specific, you may write the tag to an incorrect location.  An example of this is some Sony cameras (I think) write EXIF:ModifyDate to IFD1, instead of IFD0 which is where it is supposed to be located. So every now and then we get a post wondering why they can't change the ModifyDate .

[blue-j]

I don't have much hair left, take it easy!   

OK, this is very surprising news, I admit.  I've been working with ExifTool for a decade and did not comprehend that it didn't track the superset of a schema like IPTC Core.  I presume all XMP-iptcCore fields ARE in IPTC Core, but not all of IPTC Core is in XMP-iptcCore?

Is this not a major, important feature that is missing?  Keeping track only on the field level and not grouping across namespaces to present a complete specification?  My guess is that this is not that impactful in most regards; for example, EXIF is probably self-contained, with the occasional xmp-exif.  As are a lot of others.  IPTC and its flavors may be the real crux of the issue...?

I am not complaining.  I am very grateful for this utility.  I bring this up with the possibility of assisting and supporting this development, if my sense of it is accurate.

- J

[Phil Harvey]

I believe that there's no guarantee as to which tag gets shown when there are duplicates, as I think it depends upon the order the tags are in the file.

Correct.

I'm not sure but Composite tags may override as they are the last created.  At least that's what seems to happen with GPS tags.

Correct.

- Phil

[Phil Harvey]

Is this not a major, important feature that is missing?  Keeping track only on the field level and not grouping across namespaces to present a complete specification?

I don't understand the question, but the answer is certainly "no". 

- Phil

[blue-j]

I of course accept the answer "no," but I want to make sure that I have not misunderstood something here.  ExifTool appears to be namespace centered, with some relations among namespaces, but insofar as a *standard* uses fields from different namespace, ExifTool is not trying to do that. 

An example might be IPTC Ext, whose standard includes fields from other namespaces, like PLUS, Photohsop, etc.  So, ExifTool doesn't group those as members fo the standard; users must connect fields from different namespaces together in a standard in their application intelligence as they wish. 

All true?   - J

[Phil Harvey]

Yes.  ExifTool gives you a tool to read/write whatever metadata you want.  There are features to help deal with certain higher-level standards (eg. the MWG module and a number of the argfiles included in the full distribution, but in general ExifTool deals with the low-level details of metadata storage and doesn't impose high-level standards.

- Phil