[TIKA-4773] Expose all parsed XMP properties from images#2927
Conversation
There was a problem hiding this comment.
Pull request overview
This PR enhances the image parser’s metadata extraction to preserve and expose all XMP properties parsed by Metadata Extractor (including vendor namespaces like Google Motion Photos), and stabilizes namespace prefixes so extracted keys remain consistent across parse order.
Changes:
- Add an
XmpHandlertoImageMetadataExtractorto copy XMP properties fromXmpDirectory#getXmpProperties()into TikaMetadata. - Pre-register canonical prefixes for Google Motion Photo-related namespaces to keep emitted XMP keys stable.
- Add JUnit tests covering Motion Photo and legacy MicroVideo XMP extraction and prefix stability.
Reviewed changes
Copilot reviewed 2 out of 4 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
.../src/main/java/org/apache/tika/parser/image/ImageMetadataExtractor.java |
Adds a new handler to copy XMP properties into output metadata and registers stable namespace prefixes. |
.../src/test/java/org/apache/tika/parser/image/MotionPhotoXmpTest.java |
Introduces tests asserting vendor XMP properties are exposed and canonical prefixes are used. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| String name = property.getKey(); | ||
| String value = property.getValue(); | ||
| if (value != null && !MetadataFields.isMetadataField(name)) { | ||
| metadata.set(name, value); | ||
| } |
There was a problem hiding this comment.
Good point, fixed. It now also skips a key that already has a value, so it won't overwrite what other extractors set.
5063c3b to
085ed66
Compare
|
Adressed issues from the Copilot review and updated the title with the Jira ticket number :) |
Metadata Extractor parses the full XMP packet but only Dublin Core and XMP-MM were copied to the metadata, so properties from other namespaces (e.g. Google motion photo tags) were dropped. Copy all parsed XMP properties, and pin canonical prefixes for the Google photo namespaces so keys do not depend on parse order.
085ed66 to
a0bb9b6
Compare
|
Dunno, how you want to handle the Copilot review(s) - I think I addressed all comments, but wanted to leave it up to you to resolve the conversations. Good? |
|
I've pressed resolved. IMHO it is all good, lets wait if Tim has something to add. |
Metadata Extractor parses the whole XMP packet, but the image extractor only copies the Dublin Core and XMP-MM schemas into the metadata. Everything else is parsed and then dropped, including vendor namespaces such as the ones Google Motion Photos use.
This adds a handler that copies all parsed XMP properties (keyed by their
prefix:namepath) and skips keys that already map to a known Tika field, so normalized values are not shadowed.It also pre-registers canonical prefixes for the Google photo namespaces. XMPCore's namespace registry is process-global and keeps whichever prefix the first parsed file declares for a URI, so the same namespace can otherwise surface as
CameraorGCameradepending on parse order; pinning the prefixes keeps the keys stable.Example output for a Motion Photo, alongside the usual EXIF:
Tests cover both the current Motion Photo format and the legacy MicroVideo format, using small synthetic files.
mvn clean installfortika-parser-image-modulepasses (checkstyle, forbidden-apis, RAT, and the full test suite).Note: I do not have an Apache JIRA account yet (requested). I will add theTIKA-XXXXid to the title and commit message once the issue is filed; opening now for early feedback.