Feature request: implement im.getxmp() to return all embedded XMP meta data as XML

[laynr]

Implement image.getxmp() similar to image.getexif(), that returns all embedded XMP meta data out of an image as XML

Something like:

def getxmp(self):
    for segment, content in self.applist:
        if segment == 'APP1':
            marker, xmp_tags = content.rsplit(b'\x00', 1)
            if marker == b'http://ns.adobe.com/xap/1.0/':
                root = xml.etree.ElementTree.fromstring(xmp_tags)
return root

# Based off https://stackoverflow.com/a/32001778

FYI: This didn't work for me:
xmp_tags = self.info.get("XML:com.adobe.xmp")

I am sure this feature request has been asked before... but a search of 'XMP' in issues yielded nothing. Just asking for MVP, not write support, or tag comprehension.

XMP documentation:
Official: https://www.adobe.com/devnet/xmp.html
Helpful: https://exiftool.org/TagNames/XMP.html

Requesting output similar to the output of:
exiftool.exe -xmp:all -X image.jpg

[UrielMaD]

Hello @laynr @hugovk I'd like to take this issue, I'm already working on this.

I already got the xmp tags out of the file, I'm just wondering which output structure would be best for the getxmp() to return

I was thinking that it could be an object like the getexif(), but in this one I already got the tags name, so, instead of the tag number I could implement the actual tag name and its value

[UrielMaD]

Btw I also could just simply return its xml tree

[laynr]

Great thanks @UrielMaD!

It is probably best to keep it similar to getexif() if they return an object and adding tags name, instead of the tag number would be awesome...

That said, there is definite value in just returning the XML tree. For one, returning the XML tree may be the most future proof as you wouldn't need to stay current on new tags names.

I guess if you return an object, one of the objects functions can be to return the XML tree - perhaps that would be the best of both worlds! (but more work)

For my personal project I just used the XML tree as the parsers for XML are well established.

One thing I am noticing is that there can be multiple XMP sections in one file and not necessarily adjacent.

Thank you for taking this on. I believe it will be very useful for many people!

[UrielMaD]

Thank you @Layn, then I'll send a PR implementing xml object, I can also return the whole xml tree as string.

I get the tag names directly from what's in the xml tree so I will return only the tags that comes in that file, so if there's more xmp tags added in the future it will still return the new ones as they just come as tags attributes.

[UrielMaD]

@hugovk Changes were merged into my PR and all tests have passed

[radarhere]

Hi. Something to be aware of. Since the xml module is not secure -
https://docs.python.org/3/library/xml.etree.elementtree.html

Warning The xml.etree.ElementTree module is not secure against maliciously constructed data. If you need to parse untrusted or unauthenticated data see XML vulnerabilities.

in Pillow 8.3.0, we've added a new requirement - you will have to install defusedxml to get this method to work. See #5565 for more information

[kevinhendricks]

Any thoughts to add a parameter to getxmp() to tell it to just return the xml as a string and not a nested dict of lists and dicts that is very hard to work with to extract anything useful (it is not a nice set of name:value pairs but instead an entire xml tree shoehorned in). Even after flattening it is an issue given the complex overuse of namespaces, and non-standardized prefixes in the IPTC spec.

There are a large number of xml parsers and tools such as bs4 that can properly be used to find and extract information from xml while properly handling namespace prefix differences across implementations. No defusedxml needed as bs4 can use lxml for parsing.

It would be extremely easy to add given the xmp xml string data is available when _getxmp() is called.

Right now I have to walk the bytes of all image files looking for xmpmeta and then backtracking to validly check that the proper namespace is used. The prefix used to represent the namespace is not always "x:".

If you ever plan to support modifying or writing xmp metadata, accepting complete/validated xml as input would certainly be easier than fighting with changes to nested dictionaries and lists.

As Accessibility becomes more important to publishers of all sorts, getting the direct access to the xml as a string will simplify things for everyone.

Please consider making this slight change thereby get yourself out of the processing and repackaging of xml game.

Thank you for your time and consideration.

[kevinhendricks]

FWIW, I thought about writing a routine to convert your nested dict back to real xml but found that the use of dictionaries presents issues for sequences of identical tags "in this case "li" tags being stored (same key overwriting the earlier key).

Here is an example here just a simple snippet from the official sample image from the IPTC.

<x:xmpmeta x:xmptk="Image::ExifTool 12.50" xmlns:x="adobe:ns:meta/">
 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <rdf:Description rdf:about="" xmlns:Iptc4xmpCore="http://iptc.org/std/Iptc4xmpCore/1.0/xmlns/">
   <Iptc4xmpCore:AltTextAccessibility>
    <rdf:Alt>
     <rdf:li xml:lang="x-default">
      This is the Alt Text description to support accessibility in 2022.1
     </rdf:li>
     <rdf:li xml:lang="en">
      This is the Alt Text description to support accessibility in 2022.1
     </rdf:li>
    </rdf:Alt>
   </Iptc4xmpCore:AltTextAccessibility>

And here is that same snippet extracted from the getxmp() command:

{'xmpmeta': {'xmptk': 'Image::ExifTool 12.50', 'RDF': { 'Description': [{'about': '', 'AltTextAccessibility': {'Alt': {'li': [{'lang': 'x-default', 'text': 'This is the Alt Text description to support accessibility in 2022.1'}, {'lang': 'en', 'text': 'This is the Alt Text description to support accessibility in 2022.1'}]}}, 
...

Notice that there is only one "li" tag shown in the dict version while the actual xml has two li tags as with separate values. Also notice the missing namespace information.

So there is no easy way to walk what is returned by getxmp() to rebuild the actual xml. Even for this very very simple example that just happened to be near the top of the tree.

Trying to suss out anything farther down in the nested dict structure is an exercise in futility unless you know the entire structure in advance which kinds of defeats the whole purpose.

The actual xml is much much easier to work with and is simpler for you.

Hope this helps.