ExifTool writes XMP files differently to Adobe Bridge

[Joanna Carter]

Greetings folks

I am trying to parse an XMP file and am getting different results, depending on whether the file was written by ExifTool or Adobe.

e.g.

I am trying to parse photoshop:SidecarForExtension also known as just SidecarForExtension and I find with the ExifTool written file it is a top level element but, with the Adobe written file, it is in an attribute dictionary under rdf:Description

Is there any way I can get ExifTool to write it the same way as Adobe or do I have to conditionally parse for the two variants?

[Phil Harvey]

Without seeing the XMP that you describe, I don't know exactly what you are talking about, but it seems you may be referring to shorthand XMP format, which may be set using the ExifTool API Compact option.

- Phil

[Joanna Carter]

The xmp generated by Adobe is...

Code Select Expand


<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 5.6-c140 79.160451, 2017/05/06-01:08:21        ">
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <rdf:Description rdf:about=""
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:... (deleted for clarity)
   dc:format="image/x-nikon-nef"
    ...


... whereas the xmp generated by ExifTool is...

Code Select Expand


<?xpacket begin='' id='W5M0MpCehiHzreSzNTczkc9d'?>
<x:xmpmeta xmlns:x='adobe:ns:meta/' x:xmptk='Image::ExifTool 12.11'>
<rdf:RDF xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
<rdf:Description rdf:about=''
  xmlns:dc='http://purl.org/dc/elements/1.1/'>
  <dc:format>image/x-nikon-nef</dc:format>
    ...


It would seem the difference is the extra level for ?xpacket in the ExifTool generated file.

[Joanna Carter]

I've found the difference!

In Adobe...

Code Select Expand


  <rdf:Description rdf:about=""
    xmlns:dc="http://purl.org/dc/elements/1.1/"
   dc:format="image/x-nikon-nef"


dc:format is not marked with<...>

In Exiftool

Code Select Expand


<rdf:Description rdf:about=''
  xmlns:dc='http://purl.org/dc/elements/1.1/'>
  <dc:format>image/x-nikon-nef</dc:format>


dc:format is marked with<...>

Which, I think, means that Adobe are marking it as an attribute but ExifTool is marking it as an element.

When reading from the xmp file, ExifTool seems to ignore this difference but an XML parser doesn't 

In my parser I'm having to test for the rdf:Description element to see if it contains an attribute dictionary in order to read certain attributes.

Does that make any sense?

[Joanna Carter]

... which is where api compact=5 comes in useful.

I have now added this to my commands and no they produce the same structure as Adobe.

Thank you so much for the rubber duck consulting 

[Phil Harvey]

Note that this structure is not significant for any standard XMP parser.  It is not a difference between an attribute and an element as you were thinking.  They are both elements (normally called properties), but one is in shorthand format.  Yes, it does look like an attribute, but that is how shorthand properties are written according to the XMP specification.

Also, you should be using -api compact=all.  The old number scheme has been superceded (although it still works for backward compatibility).

- Phil

[Joanna Carter]

Also, you should be using -api compact=all.  The old number scheme has been superceded (although it still works for backward compatibility).

Great. Thanks for that.

[Phil Harvey]

Note also that older Adobe products wrote XMP in the same format as the default ExifTool format.  More recent products seem to have switched to using the shorthand format.

- Phil

[Joanna Carter]

Note also that older Adobe products wrote XMP in the same format as the default ExifTool format.  More recent products seem to have switched to using the shorthand format.

Oh, great So, I'd better leave in the conditional code anyway - just in case 

[StarGeek]

Pardon my ignorance, but isn't there existing standard code for reading/writing xmp?  It sorta sounds like you're making your own xmp read/write code.

The Adobe XMP Developer Center page has a link an XMP Toolkit SDK.

[Phil Harvey]

isn't there existing standard code for reading/writing xmp?  It sorta sounds like you're making your own xmp read/write code.

I assume this comment is directed to Joanna.  This isn't an option for ExifTool because the Adobe SDK doesn't live up to my standards.

- Phil

[Joanna Carter]

 

[StarGeek]

I assume this comment is directed to Joanna.

More of general question.  It's something I wonder about because there have been multiple times when there has been a program that can't read one form of XMP or another.

[Phil Harvey]

I see.  To answer this generally:  Yes, Adobe does provide a XMP SDK.  I believe Exiv2 for example uses this.   It could make sense for developers of C++ software running on supported platforms to use this SDK.  I never considered this as an option for ExifTool.

- Phil

[ScannerBoy]

For some time I had been looking at and using both the Adobe SDK & Exiv2, though my current project is using Exiftool.
It is my understanding that Exiv2 is currently in the process of removing the SDK code, or at least considering it.

There is however another group using the current Github version of this SDK https://github.com/fhmwg/cpp-code