New IPTC Photo Metadata Standard properties due to be introduced 20 Oct 2021

[bquinn]

Hi exiv2 team,

We at IPTC are voting on a proposed new version of IPTC Photo Metadata Standard next week (20th October).

Here's the draft of the spec.

If voted through by the Standards Committee, it will introduce three new properties. Two of them are intended to be used for accessibility, and the third is to introduce an event ID to align it with existing IDs for other elements such as organisation code.

XMP ID	Property name and link to spec	Description	Cardinality	Type
Iptc4xmpCore:AltTextAccessibility	Alt Text (Accessibility)	A brief textual description of the purpose and meaning of an image that can be accessed by assistive technology or displayed when the image is disabled in the browser. It should not exceed 250 characters.	0 .. 1	Lang Alt
Iptc4xmpCore:ExtDescrAccessibility	Extended Description (Accessibility)	A more detailed textual description of the purpose and meaning of an image that elaborates on the information provided by the Alt Text (Accessibility) property. This property does not have a character limitation and is not required if the Alt Text (Accessibility) field sufficiently describes the image.	0 .. 1	Lang Alt
Iptc4xmpExt:EventId	Event Identifier	Identifier(s) of the specific event at which the photo was taken	0 .. unbounded	Bag Text

We're aiming to have support in exiftool in the next couple of weeks. It would be great if exiv2 could also support these properties soon.

Thanks for your consideration!

Brendan Quinn, Managing Director, IPTC

(Update 18 Nov 2021: edited links to go to the published version of the spec, now that it has been released)

[postscript-dev]

Thank you for letting us know about the new IPTC standard, keeping us informed helps us to provide better support to GIMP, darktable, Krita and lots of other open source software.

For us, the timing of your update is unfortunate as the next version of Exiv2 (0.27.5) is released today and your changes couldn't be included. The release date for the next version of Exiv2 is still undecided but is not likely for several months. You can follow the discussion on Exiv2's future releases and release dates here.

Although I am working on other things at the moment, I will add your IPTC updates to my jobs list and come back to it.

We will definitely include your changes in the next version of Exiv2 although, at the moment, we cannot say when that release will be.

[bquinn]

Hi Peter, thanks very much for the update. Please let us know if we can help with the implementation.

FYI the proposed changes were accepted at our standards group meeting last week, so they are now official. We will update the standard documentation this week.

Also FYI exiftool now supports the new tags, as of version 12.33.

[postscript-dev]

Sorry for the delay, I have started work on this today.

If anyone is following this, the official IPTC Photo Metadata Standard 2021.1 specification is available here.

BTW, I think that there is a copy/paste mistake in the specification. In 9. XMP Namespaces and Identifiers, the namespace for xmp might be changed from http://ns.adobe.com/xap/1.0/rights/ to http://ns.adobe.com/xap/1.0/. As best I understand it, individually, both the namespace and name must be unique within the XMP metadata. I can't view all the Adobe specifications on their site, but an old link still works and shows the Xmp group and the Xmp Rights group namespaces.

[bquinn]

Hi Peter, that's great news, thanks!

You are correct about the XMP namespace being incorrect in the spec, thanks for spotting it.

FYI here is the relevant section from ISO 16684-1 2019, which is the current XMP spec:

8.4 XMP namespace

The XMP basic namespace contains properties that provide basic descriptive information.
— The namespace URI shall be "http://ns.adobe.com/xap/1.0/".
— The preferred namespace prefix is xmp.

[postscript-dev]

Sorry for the delay.

Although I haven't submitted a PR yet, I have added the above 3 tags to my code and decided to review all the tags in the IPTC 2021.1 specification. I hope to have this completed soon.

[postscript-dev]

@kmilos:
While reviewing the IPTC 2021.1 specification, I have found lots of tags added which actually only exist as part of structs and don't stand by themselves. For example,. Xmp.Iptc4xmpExt.AOCopyrightNotice is actually only part of the ArtworkOrObjectDetails struct (as seen in IPTC 2021.1 and ExifTool's XMP iptcExt Tags). Perhaps the confusion may have come from the IPTC specification's XMP Specs field, where it looks as though it is a separate tag and not part of a struct.

My understanding is that Exiv2 only supports the tags, not the structures, and it is up to the user to choose what value to store in the tag. If I delete all the struct-tags. as they are Xmp and the namespace is built-in, they would automatically be re-added by anyone who has already used them. If I delete the tags then it discourages others from using them. If you are happy with this interpretation then I will proceed.

While having a quick look at src/properties.cpp, I think that the same issue could be found with other specifications. Perhaps this is something to review at some point in the future.

[postscript-dev]

@clanmills: Perhaps you can help.

While reviewing the IPTC 2021.1 specification, I have found lots of tags added which actually only exist as part of structs and don't stand by themselves. For example,. Xmp.Iptc4xmpExt.AOCopyrightNotice is actually only part of the ArtworkOrObjectDetails struct (as seen in IPTC 2021.1 and ExifTool's XMP iptcExt Tags).

My understanding is that Exiv2 only supports the tags, not the structures, and it is up to the user to choose what value to store in the tag.

I can see 2 solutions to the tag problem:

1. Mark the tags as deprecated (in the label and description) and delete them in a future release.
2. Delete the erroneous tags now. If they already exist in a file's metadata then, they would be automatically re-added as the XMP namespace is already defined in Exiv2.

I have reviewed all the tags and will create a PR, but don't know which approach is preferred.

[clanmills]

@postscript-dev I think you're now the IPTC Expert in Team Exiv2. Remember the saying In the land of the blind, the one eyed man is king. I don't know much about IPTC because the code is stable and there have been very few issues raised concerning IPTC. I investigated and documented my knowledge/understanding of IPTC in my book https://clanmills.com/exiv2/book/#IPTC

Is Xmp.Iptc4xmpExt formatted as XMP? In otherwords, is the value an XML string? If that's the case, we shouldn't need a sub-structure in the IPTC code. readMetadata() should could call XmpParser::decode() to parse the XML/xmp and automatically create the sub-structures.

The following table is from http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata#iptc-extension-schema-1-6-specifications

Name	URI	Recommended Prefix
PLUS	http://ns.useplus.org/ldf/xmp/1.0/	plus
XMP	http://ns.adobe.com/xap/1.0/rights/	xmp
XMP Rights	http://ns.adobe.com/xap/1.0/rights/	xmpRights

The plus, xmp and xmpRights namespaces are already known to the system, as are Iptc4xmpCore and Iptc4xmpExt.

837 rmills@rmillsm1:~/gnu/github/exiv2/0.27-maintenance $ exiv2 --verbose --version -g right -g plus -g xmp
...
xmlns=Iptc4xmpCore:http://iptc.org/std/Iptc4xmpCore/1.0/xmlns/
xmlns=Iptc4xmpExt:http://iptc.org/std/Iptc4xmpExt/2008-02-29/
xmlns=plus:http://ns.useplus.org/ldf/xmp/1.0/
xmlns=xmp:http://ns.adobe.com/xap/1.0/
xmlns=xmpRights:http://ns.adobe.com/xap/1.0/rights/
...
838 rmills@rmillsm1:~/gnu/github/exiv2/0.27-maintenance $ 

It would be very helpful to have some sample/test files which use this feature and to have defined use-case. Is it sufficient for exiv2 to display the data, or is exiv2 expected to be able to edit it (insert, modify, delete)?

@bquinn Can you offer advice please about sample/test files. Do you know how the user would expect exiv2 to present and/or edit this data?

[kmilos]

Apologies for the silence Peter, but I have even less clue about the intricacies of XMP schemas and can't help out much here I'm afraid...

[postscript-dev]

Sorry, but in the run up to Christmas, my time was limited. Now I have more time, I plan to finish this.

@kmilos: No problem.

@clanmills: I looked back at my original message and realised that, as I was short of time, I didn't make things very clear.

The recently released IPTC specification lists XMP tags mostly found in Xmp.Iptc4xmpExt. The problem is that some of the tags that have previously been added in Xmp.Iptc4xmpExt are not stand-alone tags but actually only exist as part of structs that are used by some of the stand-alone tags.

For example, the tag Iptc4xmpExt:ArtworkOrObject uses a Bag of ArtworkOrObject structs and that struct contains several tags such as AOCopyrightNotice (see ExifTool's implementation).

In Exiv2, the Xmp.Iptc4xmpExt.ArtworkOrObject tag is correctly listed as an xmpBag with the notes explaining that the user should use bag ArtworkOrObjectDetails. The problem is that tags such as Iptc4xmpExt:AOCopyrightNotice, which only exist in a struct, have been wrongly added to Xmp.Iptc4xmpExt as stand-alone tags (i.e., Xmp.Iptc4xmpExt.AOCopyrightNotice).

For all tags, Exiv2 only supports the basic type (for XMP: XmpText, XmpAlt, XmpBag, XmpSeq and LangAlt) with the contents of the entry (or entries for arrays), up to the user (except for LangAlt which uses a fixed format). All entries are simply treated as a piece of text and any structs in the specifications are not checked/enforced. It is up to the user what values are stored in an entry. I am not considering adding further struct capability to Exiv2.

Going forward, the erroneous struct-tags need to be removed as they are not found in the specification. My query was whether the tags should simply be deleted or marked as deprecated in the label and description. If the tags are deprecated, then this would help alert anyone using them so that they can make a change. If deleted, as the tags are XMP and the namespace is built-in, any existing tags would automatically be used without incident.

@bquinn: If you don't have easy access to sample data, then I can fabricate any examples that I need.

Also while looking through the specification, I noticed some other things that I think are worth checking:
1 In 10.18 Licensor, the type is Bag Licensor structure but the supplied link to the plus website uses Seq LicensorDetail.
2. In 6.12 Description Writer, the type is Text but the photoshop:CaptionWriter tag in XMP Specification Part 2 (2016) uses ProperName. This may have been changed in the new XMP specification but I don't have access to the document.
3. In the Definition section for 6.21 Scene Code, the text should read "or" instead of "ore".

I hope these are helpful to you.

[clanmills]

@postscript-dev I think your thoughts about deprecating those tags on 'main' is the correct approach. However, don't do this on 0.27-maintenance which I hope is close to end of life.

[bquinn]

Hi all, sorry for the silence, I'm on leave right now. I'll be back in the office on Monday, and I can help properly then.

Until then these might help.

Here's an image with every IPTC property "filled in", including structured and repeating properties:
http://iptc.org/std/photometadata/examples/IPTC-PhotometadataRef-Std2021.1.jpg

exiftool can extract the raw XMP which might help. This gist is the output of exiftool -xmp -b IPTC-PhotometadataRef-Std2021.1.jpg.

[postscript-dev]

Here's an image with every IPTC property "filled in", including structured and repeating properties:
http://iptc.org/std/photometadata/examples/IPTC-PhotometadataRef-Std2021.1.jpg

This is very helpful in explaining the different tags. Is this image's metadata available for inclusion in exiv2? I can extract the metadata (as XML) from the image and this would need to be released under the project's license. If this is not possible, then the image can still help guide me in creating my own XML data.

[clanmills]

@postscript-dev @bquinn Thank You for sharing that file, Peter and Brendan.

I've looked at that with exiv2 and tvisitor (the code in my book). The file contains 26 Iptc.Application records (3xSubject + 3xKeywords + Caption etc). The XMP data includes similar data in the Iptc4xmpExt namespace.

Going back to the original request, it appears to me that Exiv2 does requires no modification to support Iptc4xmpCore:AltTextAccessibility, Iptc4xmpCore:ExtDescrAccessibility and Iptc4xmpExt:EventId.

Is this correct and we can close this issue? Or have I misunderstood?

Iptc using exiv2

716 rmills@rmillsmm-local:~/temp $ exiv2 -pi IPTC-PhotometadataRef-Std2021.1.jpg 
Iptc.Application2.ObjectAttribute            String     19  A Genre (ref2021.1)
Iptc.Application2.ObjectName                 String     21  The Title (ref2021.1)
Iptc.Application2.Subject                    String     15  IPTC:1ref2021.1
Iptc.Application2.Subject                    String     15  IPTC:2ref2021.1
Iptc.Application2.Subject                    String     15  IPTC:3ref2021.1
Iptc.Application2.Keywords                   String     17  Keyword1ref2021.1
Iptc.Application2.Keywords                   String     17  Keyword2ref2021.1
Iptc.Application2.Keywords                   String     17  Keyword3ref2021.1
Iptc.Application2.SpecialInstructions        String     26  An Instruction (ref2021.1)
Iptc.Application2.DateCreated                Date        8  2021-10-20
Iptc.Application2.TimeCreated                Time       11  21:01:01+00:00
Iptc.Application2.Byline                     String     20  Creator1 (ref2021.1)
Iptc.Application2.BylineTitle                String     32  Creator's Job Title  (ref2021.1)
Iptc.Application2.City                       String     23  City (Core) (ref2021.1)
Iptc.Application2.SubLocation                String     30  Sublocation (Core) (ref2021.1)
Iptc.Application2.ProvinceState              String     31  Province/State(Core)(ref2021.1)
Iptc.Application2.CountryCode                String      3  R21
Iptc.Application2.CountryName                String     26  Country (Core) (ref2021.1)
Iptc.Application2.TransmissionReference      String     18  Job Id (ref2021.1)
Iptc.Application2.Headline                   String     24  The Headline (ref2021.1)
Iptc.Application2.Credit                     String     23  Credit Line (ref2021.1)
Iptc.Application2.Source                     String     18  Source (ref2021.1)
Iptc.Application2.Copyright                  String     58  Copyright (Notice) 2021.1 IPTC - www.iptc.org  (ref2021.1)
Iptc.Application2.Caption                    String     39  The description aka caption (ref2021.1)
Iptc.Application2.Writer                     String     30  Description Writer (ref2021.1)
Iptc.Application2.RecordVersion              Short       1  4
717 rmills@rmillsmm-local:~/temp $ 

Xmp using Exiv2

715 rmills@rmillsmm-local:~/temp $ exiv2 -px IPTC-PhotometadataRef-Std2021.1.jpg | grep -e Access -e Event
Xmp.iptc.AltTextAccessibility                LangAlt     1  lang="x-default" This is the Alt Text description to support accessibility in 2021.1
Xmp.iptc.ExtDescrAccessibility               LangAlt     1  lang="x-default" This is the Extended Description to support accessibility in 2021.1
Xmp.iptcExt.Event                            LangAlt     1  lang="x-default" Event Name (ref2021.1)
Xmp.iptcExt.EventId                          XmpBag      2  https://example.com/events/id2021.1a, https://example.com/events/id2021.1b

Sniffing the raw XMP with tvisitor

713 rmills@rmillsmm-local:~/temp $ tvisitor -pX IPTC-PhotometadataRef-Std2021.1.jpg | xmllint --pretty 1  - | grep Iptc | grep Core | grep -e Access -e Event
      <Iptc4xmpCore:AltTextAccessibility>
      </Iptc4xmpCore:AltTextAccessibility>
      <Iptc4xmpCore:ExtDescrAccessibility>
      </Iptc4xmpCore:ExtDescrAccessibility>
714 rmills@rmillsmm-local:~/temp $ tvisitor -pX IPTC-PhotometadataRef-Std2021.1.jpg | xmllint --pretty 1  - | grep Event
      <Iptc4xmpExt:Event>
          <rdf:li xml:lang="x-default">Event Name (ref2021.1)</rdf:li>
      </Iptc4xmpExt:Event>
      <Iptc4xmpExt:EventId>
      </Iptc4xmpExt:EventId>
715 rmills@rmillsmm-local:~/temp $

[1div0]

Nice. Thank you so much.

Cheers.