SCHNELLES Tool für Exif-Daten extrahieren

[epp4]

Hi,
das Thema Exif-Daten extrahieren wurde ja schon oft behandelt. Mir geht es nun darum, eine möglichst schnelle Extrahierung vorzunehmen.

Ich habe mir nämlich ein eigenes Datenbankproggi geschrieben, mit dem ich meine Bilder verwalte. Jetzt möchte ich es noch um einige Exifdaten erweitern, welche in die Datenbankinfo einfließen sollen. Damit die Datenbankerstellung nicht ewig dauert, bräuchte ich ein Tool, welches mir möglichst schnell die Exifdaten liefert. Und zwar über einen Kommandozeilenaufruf. Es können dabei ruhig die Exif-Daten eines ganzen Bilderordners in ein File gedumpt werden.

Ich habe es zunächst mit Exiftool probiert, aber das dauert ewig. Wenn ich damit die Exif-Daten aus etwa 2500 Bilderordnern erzeugen will, bin ich fast eine Stunde unterwegs.

Kennt jemand ein Tool, welches wirklich schnell arbeitet? Ich möchte nur ein paar wichtige Daten extrahieren, wie Kameramodel, ISO, Blende, Belichtungszeit und Brennweite.

Erwin

P.S.: Optimal wäre natürlich eine fertige DLL, die man einbinden könnte, dann bräuchte man keinen Umweg über Ausgabefiles. Aber das ist wahrscheinlich ein Wunschkonzert.

 

[MasterFX]

ExifTool
Es gibt auch einige Code-Beispiele z.B. für C#, VB: http://www.google.com/search?hl=en&q=exif+class+dll&aq=f&aqi=&aql=&oq=&gs_rfai=
Aber du kannst das ja auch über Pipes alles automatisieren.

 

[epp4]

Danke für die Rückmeldung.

Wie ich schon sagte, Exiftool ist leider um Welten zu langsam. Dieses Programm ist offensichtlich zu mächtig. Da geht wohl schon zuviel Zeit beim Parsen der Eingangsparameter drauf.

Das mit den Code-Beispielen schaue ich mir einmal genauer an. Ich hatte eigentlich befürchtet, dass da deutlich mehr dahinter steckt als ein paar kB Code.

Erwin

 

[armin304]

libexif könnte vieleicht auch ganz interessant sein.

 

[MasterFX]

Du könntest auch über PHP arbeiten. Da geht das Exif auslesen auch verdammt schnell mit und du kannst es auch direkt in eine Datei schreiben. Sind nur ein paar Zeilen Code.

EDIT: Ahh hier ist nochwas: http://www.exiv2.org/#util
Habs gerade mal getestet, gut 50-100 Bilder/s bei Umleitung in eine Datei.

 

[epp4]

Ich habe jetzt eine für mich optimale Lösung gefunden. Bei codeproject.com gibt es die Source für eine Klasse Cexif im Angebot. Das sind wirklich nur ein paar kB an Code. Und es ist ein C++ Code, der praktisch ohne Formatänderung in mein Projekt passt. Wie gesagt hatte ich einen deutlich höheren Programmieraufwand erwartet, deshalb wollte ich zunächst auf ein fertiges Tool über Kommandozeile ausweichen.

Ich habe einen kurzen Probelauf über einen Ordner mit knapp 600 Files durchgeführt. In deutlich unter 1s habe ich die Exif-Daten drin.

Danke für eure Mithilfe!

Erwin

 

[epp4]

So, ich wärme diesen Thread nochmals auf, vielleicht hat jemand noch eine weitere Idee, wie man es schneller hinbekommen kann.

Vorweggenommen, die EXIf-Routine selbst ist kein Flaschenhals mehr. Ich bekomme ca. alle 12ms ein File eingelesen. Das dürfte somit eindeutig der Positionierung des Festplattenkopfes geschuldet sein. Egal ob ich nur ein paar kB einlese und gar nicht nach Exif-Daten absuche oder den ganzen vollwertigen Exifzugriff mache, es ist fast kein Unterschied mehr.

Gibt es irgendeine intelligente Einlesesoftware, mit der man den Dateizugriff beschleunigen kann? Ich stelle mir das so vor, dass man die Files nicht in der mittels FindFirst und FindNext erzeugten alphabetischen Reihenfolge liest, sondern so wie sie physikalisch hintereinander auf der HD abgelegt sind.

Erwin

 

[Markus42]

Gibt es irgendeine intelligente Einlesesoftware, mit der man den Dateizugriff beschleunigen kann? Ich stelle mir das so vor, dass man die Files nicht in der mittels FindFirst und FindNext erzeugten alphabetischen Reihenfolge liest, sondern so wie sie physikalisch hintereinander auf der HD abgelegt sind.

Findfirst/Findnext arbeiten nicht alphabetisch.

Ich glaube nicht, dass Du von diesen 12ms wegkommst. Das ist bei USB noch viel schlimmer (ich komm da so auf 50ms).

 

[epp4]

Findfirst/Findnext arbeiten nicht alphabetisch.

Ich glaube nicht, dass Du von diesen 12ms wegkommst. Das ist bei USB noch viel schlimmer (ich komm da so auf 50ms).

Also bei mir (Windows XP) wirft Findfirst/Findnext die Files in alphabetischer Reihenfolge aus. Ok, unter der FF/FN-Doku findet sich keine entsprechende Spezifikation, aber es kommt nunmal so raus.

Was man bräuchte wäre eine einfache Möglichkeit, den Startsektor jeder Datei zu ermitteln, aber ohne auf das File selbst zugreifen zu müssen. Bei einer ausreichend guten Defragmentierung sollte man mit dem Startsektor alleine klar kommen. Ob jetzt ein Einlesen der Files in der Reihenfolge der Startsektoren einen nennenswerten Geschwindigkeitsgewinn bringt, steht natürlich auf einem anderen Blatt.

Erwin

 

[Markus42]

Also bei mir (Windows XP) wirft Findfirst/Findnext die Files in alphabetischer Reihenfolge aus. Ok, unter der FF/FN-Doku findet sich keine entsprechende Spezifikation, aber es kommt nunmal so raus.

Was man bräuchte wäre eine einfache Möglichkeit, den Startsektor jeder Datei zu ermitteln, aber ohne auf das File selbst zugreifen zu müssen. Bei einer ausreichend guten Defragmentierung sollte man mit dem Startsektor alleine klar kommen. Ob jetzt ein Einlesen der Files in der Reihenfolge der Startsektoren einen nennenswerten Geschwindigkeitsgewinn bringt, steht natürlich auf einem anderen Blatt.

NTFS legt die Dateiennamen sortiert ab. Deswegen kommen die bei Dir auch sortiert raus. Diese interne Sortierung ist aber gerade bei Sonderzeichen (insb. Umlaute) nicht unbedingt immer so wie man sie erwarten würde. Diese Sortierung gibt es bei CDs/DVDs oder FAT (z.B. auf Speicherkarten) aber nicht.

Wenn Deine Festplatte aber noch nicht zu voll ist, dann sollten die Dateien eines Verzeichnisses aber schon in der Nähe zueinander liegen, so dass ich nicht glaube, dass diese Optimierung viel bringen würde. Außerdem handelt man sich mit solchem Low-Level-Zugriffen idR mehr Ärger ein als es Wert ist.

 

[epp4]

Wenn Deine Festplatte aber noch nicht zu voll ist, dann sollten die Dateien eines Verzeichnisses aber schon in der Nähe zueinander liegen, so dass ich nicht glaube, dass diese Optimierung viel bringen würde.

Vermutlich hast du Recht. Ich habe jetzt zwar zwischenzeitlich eine Routine gefunden, welche über FSCTL_GET_RETRIEVAL_POINTERS etc. etc. die Fileposition ausspuckt. Wenn ich aber weiter überlege, müsste ich meine Einleseroutine nochmals komplett umschreiben. Ich brauche nämlich die Filenamen alphabetisch ausgegeben, d.h. ich müsste alle Filedaten eines Verzeichnisses erst in einem Zwischenpuffer abspeichern, bevor ich sie ins Summary schreibe, da die physikalische Einlesefolge nicht mehr dem Alphabet entspricht.

Das Thema < 12ms schiebe ich erstmal auf Prio 2 - liegende 8 .

Erwin