Copilot commented on code in PR #2927:
URL: https://github.com/apache/tika/pull/2927#discussion_r3526861257
##########
tika-parsers/tika-parsers-standard/tika-parsers-standard-modules/tika-parser-image-module/src/main/java/org/apache/tika/parser/image/ImageMetadataExtractor.java:
##########
@@ -306,6 +310,51 @@ public void handle(Directory directory, Metadata metadata)
throws MetadataExcept
}
}
+ /**
+ * Copies the XMP properties parsed by Metadata Extractor into the
metadata,
+ * keyed by their {@code prefix:name} path. The other handlers copy a
+ * directory's tags, but XMP keeps its properties in a separate map
+ * ({@link XmpDirectory#getXmpProperties()}), so without this they are
lost.
+ * Keys matching a known Tika field are skipped.
+ */
+ static class XmpHandler implements DirectoryHandler {
+
+ static {
+ // XMPCore's namespace registry is process-global and keeps the
first
+ // prefix it sees for a URI. Pin canonical prefixes so keys stay
stable
+ // (files use both Camera and GCamera for the Google photo
namespace).
+ // https://developer.android.com/media/platform/motion-photo-format
+ try {
+ XMPMetaFactory.getSchemaRegistry()
+
.registerNamespace("http://ns.google.com/photos/1.0/camera/";, "Camera");
+ XMPMetaFactory.getSchemaRegistry()
+
.registerNamespace("http://ns.google.com/photos/1.0/container/";, "Container");
+ XMPMetaFactory.getSchemaRegistry()
+
.registerNamespace("http://ns.google.com/photos/1.0/container/item/";, "Item");
+ } catch (XMPException e) {
+ // non-fatal: only affects prefix stability
+ }
+ }
+
+ public boolean supports(Class<? extends Directory> directoryType) {
+ return XmpDirectory.class.isAssignableFrom(directoryType);
+ }
+
+ public void handle(Directory directory, Metadata metadata) throws
MetadataException {
+ Map<String, String> properties = ((XmpDirectory)
directory).getXmpProperties();
+ if (properties == null) {
+ return;
+ }
+ for (Map.Entry<String, String> property : properties.entrySet()) {
+ String name = property.getKey();
+ String value = property.getValue();
+ if (value != null && !MetadataFields.isMetadataField(name)) {
+ metadata.set(name, value);
+ }
Review Comment:
XmpHandler currently overwrites any existing metadata value for the same XMP
key. This can unintentionally replace values set earlier by other extractors
(e.g., JempboxExtractor sets XMPMM.* keys such as "xmpMM:DocumentID"), because
MetadataFields only tracks fields from Metadata and TikaCoreProperties and
therefore may not treat those XMP keys as "known". To avoid shadowing
normalized/existing values, skip setting an XMP property when metadata already
contains a value for that key.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
