Manchmal, wenn Sie ein Bild herunterladen und die Verbindung während des Streams unterbrochen wird, verbleibt ein halb heruntergeladenes Bild. Wenn Sie versuchen, es anzuzeigen, erhalten Sie den oberen Teil des Bildes und der untere Teil ist normalerweise grau oder grün oder eine andere Farbe. Mit anderen Worten, es ist beschädigt.
Gibt es eine Möglichkeit zu überprüfen, ob das Bild auf diese Weise beschädigt oder auf andere Weise beschädigt ist?
Antworten:
Wenn Sie über JPEG-Dateien sprechen, ist das Dienstprogramm jpeginfo genau das, wonach Sie suchen. Es kann Dateien auf verschiedene Arten von JPEG-Fehlern und Korruption prüfen und entweder einen Fehlercode zurückgeben (das nützlichste für Skripterstellung) oder einfach Dateien mit Fehlern löschen.
Ich verwende dies als Teil meiner anfänglichen Dateiübertragung, um sicherzustellen, dass alles in Ordnung kopiert wird, ohne auf manuelle Überprüfung angewiesen zu sein. (Danach stelle ich sicher, dass sich ihre Prüfsummen im Rahmen meines normalen Backup- / Bitrot-Schutzes nicht ändern.)
Das Programm ist eine Befehlszeile und wird als Quellcode geliefert. Es sollte jedoch auf jeder Linux-Distribution oder auf einem Mac mit einer ordnungsgemäß eingerichteten Entwicklungsumgebung einfach zu erstellen und zu verwenden sein. Ich bin sicher, Sie könnten es sogar unter Windows mit Cygwin oder MinGW machen. (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 erstellen Sie ihn selbst:
$ git clone https://github.com/tjko/jpeginfo.git
Cloning into 'jpeginfo'...
[...]
Checking connectivity... done
$ cd jpeginfo/
$ ./configure && make
Dies sollte einen jpeginfoBefehl erstellen, den Sie entweder ausführen oder kopieren können, wo immer Sie möchten (möglicherweise mit make install).
Dann führen Sie 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 völlig in Ordnung, und test2.jpg habe ich ein paar Bytes am Ende gelöscht, und test3.jpg habe ich einige zufällige Bytes im Header geändert.
Wenn Sie über RAW-Dateien verfügen, besuchen Sie diese Seite der American Society of Media Photographers zur DNG-Validierung oder eine Seite mit Informationen zur Datenvalidierung , die die Verwendung des DNG-Konverters von Adobe zur Stapelvalidierung proprietärer RAW-Formate behandelt. (Leider ist dies eine GUI-Operation und nicht unbedingt leicht zu skripten.)
Wenn Sie eine Kamera haben, die von Haus aus die Version 1.2 von DNG ausgibt, ist dies sogar noch besser, da diese eine integrierte MD5-Prüfsumme der Bilddaten enthält. Leider scheint dies nicht mit den normalen Bild-Metadaten gespeichert zu sein - oder zumindest wird es von exiftool und exiv2 nicht erkannt und es werden generell 1.2-DNG-Dateien gelesen - was nach meinem Kenntnisstand derzeit die Adobe-Validierung bedeutet Dies kann nur mit dem Tool genutzt werden.
ImageVerifier hat getan, was Sie wollten. Leider steht es nicht mehr zum Download zur Verfügung und der Support wurde am 31. Dezember 2017 eingestellt (siehe Ingestamatic und ImageVerifier nicht mehr zum Verkauf ).
ImageVerifier (kurz IV) durchläuft eine Hierarchie von Ordnern, die nach zu überprüfenden Bilddateien suchen. Es kann TIFFs und JPEGs überprüfen. PSDs, DNGs und Nicht-DNG-Raws (z. B. NEF, CR2).
IV ist für die Verarbeitung einer großen Anzahl von Bildern ausgelegt. Ordnerhierarchien mit 100.000 Bildern oder mehr sollten kein Problem sein. In einem Testlauf lief IV 14 Stunden.
Es gibt zwei Arten der Überprüfung, die IV durchführt: Strukturprüfung und Hash-Prüfung.
Wenn es nicht darum geht, Bilder von Ihrer Kamera herunterzuladen, sondern von Computer zu Computer zu übertragen, sind Prüfsummen ein gängiger Ansatz für die Dateiintegrität .
Leider werden, soweit ich weiß, gängige "Endbenutzer" -Bildformate (JPEG, PNG, GIF, ...) nicht eigenständig auf Integrität geprüft. Aus meiner Sicht ist die Integration von Prüfsummen-Tools ( CRC32 , MD5 , ...) in den Workflow eine praktikable Lösung. Ein gemeinsamer Ansatz die Prüfsumme zu speichern ist eine Datei mit dem gleichen Dateinamen zu haben, nur mit einer zusätzlichen Erweiterung, wie: img123.jpg → img123.jpg.md5.
Dieser Ansatz hat den zusätzlichen Vorteil, dass Sie auch die Integrität von (z. B.) Sidecar-Dateien oder anderen Elementen, die Sie auf ähnliche Weise übertragen möchten, überprüfen können. Und wenn Sie die Prüfsummendateien auch in Zukunft behalten. (Und es hat den Nachteil, dass es meines Wissens nach nicht in PS, LR oder die anderen gängigen Tools integriert ist.)
Ich habe check_media_integrity als einfaches Python-Skript entwickelt check_mi.py, das Sie von GitHub herunterladen können:
https://github.com/ftarlao/check-media-integrity
Ich zitiere das Handbuch-Intro:
check-mi ist ein Python 2.7-Skript, das die Integrität von Mediendateien (Bilder, Video, Audio) automatisch überprüft. Sie können die Integrität einer einzelnen Datei oder einer Reihe 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 ihren Details im CSV-Format ausgeben.
Das Tool testet die Dateiintegrität mithilfe gängiger Bibliotheken (Pillow, ImageMagik, FFmpeg) und überprüft, ob die Mediendateien tatsächlich dekodiert werden können. Warn-, Bild-, Audio- und Videoformate sind sehr widerstandsfähig gegenüber Fehlern und Beschädigungen. Aus diesem Grund kann das Tool nicht alle beschädigten Dateien erkennen.
check-mi kann mit 100% iger Sicherheit Dateien erkennen, die fehlerhafte Header- / Metadaten, abgeschnittene Bilddateien (mit strict_level> 0) und Geräte-E / A-Fehler aufweisen.
check-mi kann in der Regel nicht alle geringfügigen Schäden erkennen - z. B. kleine Teile der Mediendatei, die mit unterschiedlichen Werten überschrieben wurden. Im Detail habe ich strict_level 1 mit einem kleinen zufälligen Experiment getestet, das auf einem einzelnen 5MB-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 Wahrscheinlichkeit von 50% für die Erkennung des Schadens zu erhalten. Wenn Sie einen Teil (Intervall) der Bilddatei mit unterschiedlichen Zufallswerten überschreiben, erhalten Sie eine Erkennungsrate von ca. 85% für Intervallgrößen von 4096 Byte bis 1024 KB.
Wenn Sie wissen, wie Sie Pillow, Wand und FFmpeg anweisen können, beim Dekodieren strenger vorzugehen, sagen Sie es mir bitte.
Die akzeptierte Antwort bezieht sich auf die Verwendung von jpeginfo, einem wirklich alten und nicht gewarteten Tool, das in C geschrieben ist (und auch nicht sehr modular / erweiterbar ist). Außerdem scheint dieses Tool nur nach bestimmten EXIF-Datenpunkten zu suchen (überfliegen Sie den Quellcode ~ 5 Minuten lang).
IMO, ein besseres Tool namens " Dateityp" , ist sehr einfach zu verwenden. Kopieren Sie den Beispielcode und ändern Sie den Dateinamen, wenn Sie nicht wissen, wie man codiert. Es überprüft die magischen Zahlen, die mit bestimmten bekannten Dateitypen verknüpft sind, und zeigt an, mit welcher Art von Datei Sie es zu tun haben.
Ich suche immer noch mehr Schutzschichten als nur diese. Wenn beispielsweise beliebige Daten hinter (oder in) den EXIF-Metadaten oder nach den magischen Zahlen gespeichert werden, kann dies zu Sicherheitsproblemen führen. Ich werde mich weiterhin mit weiteren Sicherheitsmaßnahmen befassen und hoffe, diese Antwort später zu aktualisieren.
Hier ist der Beispielcode, der von ihrer Webseite für die Faulen kopiert wurde:
// 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, als meine ursprüngliche Antwort hier) und sie haben derzeit 3.691.850 wöchentliche Downloads - das ist also wahrscheinlich ein guter Hinweis.
file(das auf die gleiche Weise arbeitet) korrekt berichtet, das jedoch nicht gerendert werden kann, da ein Großteil der Daten tatsächlich fehlt.