Missing XMP directory in JPG with XMP metadata

[theefer]

It seems like XMP metadata isn't reliably extracted even when ExifTool shows XMP being present.

For instance the following image:

Has XMP metadata according to exiftool:

$ exiftool -xmp:* Tests/Data/withXmp.jpg 
XMP Toolkit                     : XMP Core 4.1.1
Date Created                    : 2015:01:22 00:00:00+00:00
...
$ exiftool -xmp:* Tests/Data/withXmp.jpg | wc -l
32

However doing the following returns null:

Metadata metadata = JpegMetadataReader.readMetadata(new File("Tests/Data/withXmp.jpg"));
Directory directory = metadata.getFirstDirectoryOfType(XmpDirectory.class);
// directory is null

See failing test in my sc-missing-xmp branch, based on current master.

Is this because none of the tags present match the hardcoded tags in XmpDirectory? If so, is there another way to get hold of an XmpDirectory instance so that I can extract custom tags using XmpDirectory.getXmpProperties()?

[drewnoakes]

Finally had a minute to look at this.

Hex editor shows there is definitely XML data in the file. ExtractJpegSegmentTool shows the XMP is in the second (of two) APP1 JPEG segments. I guess the library doesn't know to look for it here. Will investigate further now and try to get a fix in tonight.

[drewnoakes]

Seems that the data in this file has a strange (invalid?) preamble:

http://ns.adobe.com/xap/1.0/\0<?xpacket    // normal
XMP\0://ns.adobe.com/xap/1.0/\0<?xpacket   // this file

Seems that the regular preamble has had a null-terminated XMP written over the top of it.

I'll patch XmpReader to cater for this (error?) case.

[theefer]

Great, thanks for fixing this! Would it be worth merging my PR (with tests now passing) to catch any regression of this issue?

I confess I don't know half as much as I'd need to know if this preamble is valid or not. However this issue arises with seemingly all files we get from Getty and other image agencies, so I'm erring toward this being valid somehow (not that this is always a proof of metadata quality, mind you...).

[theefer]

I noticed it wasn't actually a PR, but it is now, at #104

[drewnoakes]

Interesting. If it's that common, then perhaps there's another standard I haven't come across. It works now, which is the main thing.

[theefer]

Is there any chance to get this fix published as a patch release? We have a feature that depends on being able to extract XMP metadata from such files...

On a separate note, I have been trying to add support for Getty's custom XMP namespace (which can be seen in that test file) to the library, still working on it but I'm hoping to open it as a PR at some point.

Thanks again for the fix!

[theefer]

I've further tested the latest master locally by building the JAR and loading it into our app -- all works great now!

Is there anything I could do to help get a patch release out for this?

[drewnoakes]

Good to hear. I'll get a release out in the next day or two. Hopefully
tonight.

On Mon, 20 Apr 2015 17:31 Sébastien Cevey notifications@github.com wrote:

I've further tested the latest master locally by building the JAR and
loading it into our app -- all works great now!

Is there anything I could do to help get a patch release out for this?

—
Reply to this email directly or view it on GitHub
#102 (comment)
.

[theefer]

Amazing, thanks a lot!

[drewnoakes]

Just released 2.8.1 to Maven Central. Should be available within a couple of hours.

[theefer]

We've released the updated library to production, works great. Thanks again!