Manchmal, wenn Sie ein Bild herunterladen und die Verbindung mitten im Stream unterbrochen wird, bleibt ein halb heruntergeladenes Bild zurück. Wenn Sie versuchen, es anzuzeigen, erhalten Sie den oberen Teil des Bildes und der untere Teil ist normalerweise grau oder grün oder in einer anderen Farbe gefärbt. Mit anderen Worten, es ist beschädigt.
Gibt es eine Möglichkeit zu überprüfen, ob das Bild auf diese Weise beschädigt oder anderweitig beschädigt ist?
Wenn Sie über JPEG-Dateien sprechen, dann ist das Dienstprogramm jpeginfo genau das, wonach Sie suchen. Es kann Dateien auf verschiedene Arten von JPEG-Fehlern und Beschädigungen überprüfen und entweder einen Fehlercode zurückgeben (das Nützlichste für Skripte) oder einfach Dateien mit Fehlern löschen.
Ich verwende dies als Teil meiner anfänglichen Dateiübertragung, um sicherzustellen, dass alles korrekt kopiert wurde, ohne mich auf eine manuelle Überprüfung verlassen zu müssen. (Danach stelle ich sicher, dass sich ihre Prüfsummen im Rahmen meines normalen Backup-/Bitrot-Schutzes nicht ändern.)
Das Programm ist ein Befehlszeilenprogramm und wird als Quellcode geliefert, aber es sollte einfach zu erstellen und auf jeder Linux-Distribution oder auf einem Mac mit einer ordnungsgemäß eingerichteten Entwicklungsumgebung zu verwenden sein. Ich bin sicher, Sie könnten es sogar unter Windows mit Cygwin oder MinGW machen. (Zum Beispiel, obwohl ich nicht für seine Integrität bürgen kann, scheint dieser Blog-Beitrag legitim zu sein und enthält einen vorkompilierten Download.) So bauen Sie ihn selbst:
$ git clone https://github.com/tjko/jpeginfo.git
Cloning into 'jpeginfo'...
[...]
Checking connectivity... done
$ cd jpeginfo/
$ ./configure && make
Dies sollte einen jpeginfo
Befehl erstellen, den Sie entweder an Ort und Stelle ausführen oder kopieren können, wo immer Sie möchten (möglicherweise mit make install
).
Dann führst du es so aus:
$ ./jpeginfo -c *.jpg
test1.jpg 1996 x 2554 24bit Exif P 6582168 [OK]
test2.jpg 1996 x 2554 24bit Exif P 6582116 Premature end of JPEG file [WARNING]
test3.jpg Corrupt JPEG data: 1 extraneous bytes before marker 0xe2 1996 x 2554 24bit Exif P 6582169 [WARNING]
Hier ist test1.jpg vollkommen in Ordnung, und test2.jpg habe ich am Ende ein paar Bytes gelöscht, und test3.jpg habe ich einige zufällige Bytes im Header geändert.
Wenn Sie RAW-Dateien haben, sehen Sie sich diese Seite der American Society of Media Photographers zur DNG-Validierung oder eine Seite zu Datenvalidierungsdetails an , die die Verwendung des DNG-Konverters von Adobe zur Batch-Validierung proprietärer RAW-Formate behandelt. (Leider ist dies eine GUI-Operation und nicht unbedingt leicht skriptfähig.)
Wenn Sie eine Kamera haben, die nativ die Version 1.2 von DNG ausgibt, ist das sogar noch besser, da diese eine eingebaute MD5-Prüfsumme der Bilddaten enthält. Leider scheint dies nicht mit den normalen Bildmetadaten gespeichert zu sein – oder zumindest exiftool und exiv2 erkennen es nicht und lesen im Allgemeinen 1.2-DNG-Dateien – was bedeutet, dass meines Wissens derzeit die Adobe-Validierung durchgeführt wird Tool ist die einzige Möglichkeit, dies auch zu nutzen.
Wenn es nicht um das Herunterladen von Bildern von Ihrer Kamera, sondern um eine Übertragung von Computer zu Computer geht, sind Prüfsummen ein gängiger Ansatz zur Dateiintegrität .
Leider werden, soweit ich weiß, gängige "Endbenutzer"-Bildformate (jpeg, png, gif, …) nicht von sich aus auf Integrität geprüft. Aber da ich die Frage so verstehe, dass sie eine automatisierte Verarbeitung impliziert, könnte die Integration von Prüfsummen-Tools ( CRC32 , MD5 , …) in den Workflow eine praktikable Lösung sein. Ein gängiger Ansatz zum Speichern der Prüfsumme besteht darin, eine Datei mit demselben Dateinamen zu haben, nur mit einer hinzugefügten Erweiterung, wie: img123.jpg → img123.jpg.md5
.
Dieser Ansatz hat den zusätzlichen Vorteil, dass Sie auch die Integrität von (zum Beispiel) Sidecar-Dateien oder allem anderen, was Sie übertragen möchten, in einem ähnlichen Mechanismus überprüfen können. Und wenn Sie die Prüfsummendateien auch in Zukunft aufbewahren. (Und es hat den Nachteil, dass es nach meinem begrenzten Wissen nicht in PS, LR oder die anderen gängigen Tools integriert ist.)
ImageVerifier hat getan, was Sie wollten. Leider ist es nicht mehr zum Download verfügbar und der Support wurde am 31. Dezember 2017 eingestellt (siehe Ingestamatic und ImageVerifier nicht mehr zum Verkauf ).
ImageVerifier (kurz IV) durchläuft eine Ordnerhierarchie auf der Suche nach zu überprüfenden Bilddateien. Es kann TIFFs, JPEGs überprüfen. PSDs, DNGs und Nicht-DNG-Rohdaten (z. B. NEF, CR2).
IV wurde entwickelt, um eine große Anzahl von Bildern zu verarbeiten. Ordnerhierarchien mit 100.000 Bildern und mehr sollten kein Problem darstellen. In einem Testlauf lief IV 14 Stunden lang.
Es gibt zwei Arten der Überprüfung, die IV durchführt: Strukturprüfung und Hash-Prüfung.
Ich habe check_media_integrity ein einfaches Python-Skript entwickelt check_mi.py
, Sie können es von GitHub herunterladen:
https://github.com/ftarlao/check-media-integrity
Ich zitiere die Einleitung des Leitfadens:
check-mi ist ein Python 2.7-Skript, das automatisch die Integrität von Mediendateien (Bilder, Video, Audio) prüft. Sie können die Integrität einer einzelnen Datei oder einer Gruppe von Dateien in einem Ordner und Unterordnern rekursiv überprüfen, schließlich können Sie optional die Liste der fehlerhaften Dateien mit ihrem Pfad und Details im CSV-Format ausgeben.
Das Tool testet die Dateiintegrität mit gängigen Bibliotheken (Pillow, ImageMagik, FFmpeg) und prüft, wann sie die Mediendateien effektiv dekodieren können. Warn-, Bild-, Audio- und Videoformate sind sehr widerstandsfähig gegenüber Fehlern und Beschädigungen, weshalb das Tool nicht alle beschädigten Dateien erkennen kann.
check-mi ist in der Lage, mit 100-prozentiger Sicherheit Dateien mit fehlerhaften Header-/Metadaten, abgeschnittenen Bilddateien (mit strict_level >0) und Geräte-I/O-Fehlern zu erkennen.
check-mi ist normalerweise nicht in der Lage, alle kleineren Schäden zu erkennen – zB kleine Teile einer Mediendatei, die mit anderen Werten überschrieben wurden. Im Detail habe ich strict_level 1 mit einem kleinen randomisierten Experiment getestet, das auf einem einzelnen 5-MB-JPEG-Bild ausgeführt wurde:
Wenn Sie einen Teil (Intervall) der Bilddatei mit Nullen überschreiben, benötigen Sie eine Intervallgröße von 1024 KByte, um eine 50-prozentige Chance zu haben, den Schaden zu erkennen. Wenn Sie einen Teil (Intervall) einer Bilddatei mit unterschiedlichen Zufallswerten überschreiben, erhalten Sie eine Erkennungsrate von etwa 85 % für Intervallgrößen von 4096 Bytes bis 1024 KB.
Falls Sie Möglichkeiten kennen, Pillow, Wand und FFmpeg anzuweisen, beim Decodieren strenger vorzugehen, sagen Sie es mir bitte.
Die akzeptierte Antwort bezieht sich auf die Verwendung von jpeginfo, einem wirklich alten und nicht gepflegten Tool, das in C geschrieben ist (und auch nicht sehr modular / erweiterbar). Außerdem scheint dieses Tool nur nach bestimmten EXIF-Datenpunkten zu suchen (überfliegen Sie den Quellcode für ca. 5 Minuten).
IMO, ein besseres Tool namens file-type , ist sehr einfach zu verwenden – kopieren Sie einfach den Beispielcode und ändern Sie den Dateinamen, wenn Sie nicht wissen, wie man codiert. Es überprüft die magischen Zahlen , die bestimmten bekannten Dateitypen zugeordnet sind, und teilt Ihnen mit, mit welcher Art von Datei Sie es zu tun haben.
Ich suche immer noch nach mehr Schutzschichten als nur dieser. Wenn beispielsweise beliebige Daten nach (oder in) den EXIF-Metadaten oder nach den magischen Zahlen gespeichert werden, kann dies Sicherheitsprobleme aufwerfen. Ich werde mich weiterhin mit weiteren Sicherheitsmaßnahmen befassen und hoffe, diese Antwort später aktualisieren zu können.
Hier ist der Beispielcode, der von ihrer Webseite kopiert wurde, für die Faulen:
// Node.js
const readChunk = require('read-chunk');
const fileType = require('file-type');
const buffer = readChunk.sync('unicorn.png', 0, fileType.minimumBytes);
fileType(buffer);
//=> {ext: 'png', mime: 'image/png'}
Zu Ihrer Information, dieses Tool wird ständig aktualisiert (vor 3 Tagen war das letzte Update, wie aus meiner ursprünglichen Antwort hier hervorgeht) und sie haben derzeit 3.691.850 wöchentliche Downloads – das ist also wahrscheinlich ein guter Hinweis.
file
(das auf die gleiche Weise funktioniert) korrekt berichtet, aber nicht gerendert werden kann, da viele der Daten tatsächlich fehlen.
Turm
Turm
Turm
mattdm
Turm
Benutzer3773048