2013-10-03 8 views
8

Um meine Bildverarbeitungssoftware ExifTool verwenden, um Exif-Informationen aus Cr2, TIFF, JPG-Dateien erfolgreich shuffle. Die hinzugefügten Tags, wie zum Beispiel "keywords", sind alle in OSX (Berglöwe) Finder, Vorschau und von Spotlight schön indiziert.Exiftool zum Erstellen von OSX sichtbaren XMP-Metadaten in PNG-Bildern

Für PNGs muss ich auf XMP zurückgreifen, da dies der Metadaten-Container für PNG ist. ExifTool-hinzugefügte Tags scheinen jedoch weder von Preview noch von SpotLight übernommen zu werden. Wenn ich dagegen zuerst ein Tag in Preview hinzufüge und exiftool verwende, um später ein neues Tag hinzuzufügen, wird dieses IS indexiert. Der Unterschied hier sehe ich hier in den XMP-Rohdaten, wo exiftool neu einen Header erstellt, während Preview das nicht tut.

Als Beispiel sehen Sie die folgenden PNG aus der Wikipedia-Seite über PNG ohne Metadaten https://upload.wikimedia.org/wikipedia/commons/4/47/PNG_transparency_demonstration_1.png:

Sample PNG without metadata

ein Schlüsselwort Hinzufügen mit exiftool, und danach den XMP-Datenblock Dumping:

exiftool -xmp-dc:subject=ViaExifSubject ./PNG_transparency_demonstration_1.png 
exiftool -xmp -b ./PNG_transparency_demonstration_1.png 

Gibt die folgenden XMP-Daten:

<?xpacket begin='' id='W5M0MpCehiHzreSzNTczkc9d'?> 
<x:xmpmeta xmlns:x='adobe:ns:meta/' x:xmptk='Image::ExifTool 9.02'> 
    <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:subject> 
    <rdf:Bag> 
    <rdf:li>ViaExifSubject</rdf:li> 
    </rdf:Bag> 
    </dc:subject> 
</rdf:Description> 
</rdf:RDF> 
</x:xmpmeta> 
<?xpacket end='r'?> 

Im Infofenster "Vorschau" oder "Finder" wurde jedoch kein "ViaExifSubject" gefunden.

Alternativ OSX-Vorschau zum Hinzufügen von Kommentaren verwenden (In der Vorschau öffnen, Informationen anzeigen, zum Tab "Keywords" wechseln und auf "+" klicken, um ein Stichwort hinzuzufügen). XMP abgeladen wieder über exiftool:

<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="XMP Core 5.1.2"> 
    <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:subject> 
      <rdf:Bag> 
       <rdf:li>viaPreview</rdf:li> 
      </rdf:Bag> 
     </dc:subject> 
     </rdf:Description> 
    </rdf:RDF> 
</x:xmpmeta> 

Der xpacket Header nicht vorhanden ist, in der Vorschau Schlüsselwort erzeugt und das XMP Toolkit ist anders. Das "viaPreview" -Tag ist jetzt sichtbar, z. Verwenden Sie mdls auf dem CLI.

Pushing rohe XMP Info in eine sauber Datei nicht gibt auch nicht das erwartete Ergebnis:

exiftool "-xmp<=viaexif.xmp" PNG_transparency_demonstration_1.png 

Überraschenderweise wenn ich einen Tag mit Vorschau erstellen und tun Sie dann dem Befehl über die neuen Tags werden reflektiert Ich vermute, dass ich einen externen Datenparser beaufsichtige, der "aktiviert" werden muss, nimmt die Tags auf und legt sie in einem anderen Speicher ab (zB .DS_store). Ich habe noch keinen xattr gesehen.

Dies sind meine Fragen:

  • Ist exiftool das richtige Werkzeug für XMP/PNG-Kombination, und bin ich dabei eine bestimmte Funktion
  • Ist OSX ein XMP-Standard trotzt? Edit: apparently XMP wird nicht von OSX standardmäßig respektiert
  • Soll ich untersuche in einem alternativen Werkzeug, um den Behälter strippen?

grub ich meine xmp_sdk auf meiner Festplatte und experimentierte mit den zur Verfügung gestellten Proben:

ModifyXMP kann „reine“ XMP Info in PNG schreiben, die in OSX Finder angezeigt wird - dies ist ein guter Ziel.

ReadingXMP kann XMP-Informationen lesen, die von ExifTool in PNG eingefügt wurden, obwohl diese Informationen im OSX-Finder nicht angezeigt werden.

Die Dateigröße ist ähnlich, wenn man sich die Ausgabe und das Exiftool von ModifyXMP ansieht, die den exakt gleichen XMP-Blob einfügen. Ein Diff zeigt an, dass Exiftool am Ende der Datei hängt, wo XMP sdk es in den Header des PNG einfügt. Die XMP spec besagt, dass "Encoders aufgefordert werden, den Chunk am Anfang der Datei zu platzieren, aber das ist nicht erforderlich."

Fazit: Es gibt einen (leichten) Unterschied in der Art und Weise, wie Exiftool XMP schreibt und dies vermasselt insbesondere den Abruf von OSX-Metadaten.

Vorerst:

  • Experiment mit XMP SDK stattdessen ein sauberen XMP-Paket am Anfang einzufügen, und hat exiftool diesen ersten Block wiederverwenden.
  • I reposted on exiftools' forum und Autor Phil Harvey antwortete:

    Ich habe einige mit Apple Preview zu spielen, und nicht nur, dass es nicht XMP am Ende der Datei erkennen, sondern auch löscht es diese XMP beim Hinzufügen Schlüsselwörter zum Bild. Meine Vermutung ist, dass Apple Software XMP ignoriert, wenn es nach dem IDAT-Chunk kommt. Es wäre wunderbar gewesen, wenn die XMP-Spezifikation vorgeschrieben hätte, dass der XMP-Block vor IDAT steht, aber das tat es nicht, also muss dies als ein Fehler in der Apple-Software betrachtet werden. Ich habe dies der list of Known problems hinzugefügt.

    Schließlich Phil Harvey beschlossen, dieses Problem in Exiftool zu beheben selbst:

    ich eine Menge Arbeit geleistet haben, und Exiftool 9,40 wird eine neue Option haben, damit Sie schreiben XMP vor dem PNG IDAT-Chunk. Der entsprechende Befehl wird wie folgt aussehen: exiftool -api PNGEarlyXMP ...

  • Filed einen Fehler bei Apple - Update Dezember 2014: Apple-schloß meine Fehler besagen, dass sie keine Maßnahmen zu diesem Thema nicht nehmen

Antwort

0
  1. Sie versuchen XMP Toolkit SDK und seine Beispiele und schreiben Metadaten für PNG.
  2. OSX nutzt IPTC (nicht sicher, habe irgendwo gelesen) und XMP-Toolkit tut XMP und IPTC Einklang zu bringen, damit das Schlüsselwort hinzugefügt XMP Toolkit wird unter OS X durchsucht werden

aus Ihrer Beobachtung es wie exiftool doesn aussieht IPTC und XMP nicht abgleichen. Was Sie versuchen könnten, ist zu versuchen, sowohl IPTC und XMP in PNG zu ändern und zu sehen, ob es durchsuchbar ist.

+0

Ich bearbeitet den Beitrag, um das XMP-SDK-Verhalten einzuschließen. Ich glaube nicht, dass IPTC hier gebraucht wird (nicht direkt in PNG unterstützt). – gdh

+0

Ich gebe Ihnen die Credits für die XMP SDK-Route, die das Finden der Reihenfolge der XMP-Pakete in der PNG ausgelöst hat - wir werden sehen, wo dies endet – gdh

Verwandte Themen