Parfois, lorsque vous téléchargez une image et que la connexion est interrompue à mi-chemin, vous vous retrouvez avec une image à moitié téléchargée. Si vous essayez de l'afficher, vous obtenez la partie supérieure de l'image et la partie inférieure est généralement de couleur grise ou verte ou d'une autre couleur. En d'autres termes, il est corrompu.
Existe-t-il un moyen de vérifier si l'image est endommagée de cette manière ou autrement corrompue?
Réponses:
Si vous parlez de fichiers JPEG, l'utilitaire jpeginfo est exactement ce que vous recherchez. Il peut vérifier les fichiers pour différents types d'erreurs JPEG et de corruption et retourner un code d'erreur (la chose la plus utile pour les scripts), ou simplement supprimer les fichiers contenant des erreurs.
J'utilise cela dans le cadre de mon transfert de fichier initial, pour m'assurer que tout est bien copié sans compter sur une vérification manuelle. (Après cela, je m'assure que leurs sommes de contrôle ne changent pas dans le cadre de ma protection normale de sauvegarde / bitrot.)
Le programme est en ligne de commande et est fourni en code source, mais il devrait être facile à construire et à utiliser sur n'importe quelle distribution Linux ou sur un Mac avec un environnement de développement correctement configuré. Je suis sûr que vous pourriez même le faire sur Windows avec Cygwin ou MinGW. (Par exemple, bien que je ne puisse pas garantir son intégrité, ce billet de blog semble légitime et inclut un téléchargement précompilé.) Pour le créer vous-même:
$ git clone https://github.com/tjko/jpeginfo.git
Cloning into 'jpeginfo'...
[...]
Checking connectivity... done
$ cd jpeginfo/
$ ./configure && make
Cela devrait créer une jpeginfocommande que vous pouvez exécuter sur place ou copier où vous le souhaitez (éventuellement en utilisant make install).
Ensuite, vous l'exécutez comme ceci:
$ ./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]
Ici, test1.jpg est parfaitement bien, et test2.jpg j'ai supprimé quelques octets de la fin, et test3.jpg j'ai changé quelques octets aléatoires dans l'en-tête.
Si vous avez des fichiers RAW, consultez cette page de l'American Society of Media Photographers sur la validation DNG , ou une sur les détails de validation des données , qui couvre l'utilisation du convertisseur DNG d'Adobe pour valider par lots les formats RAW propriétaires. (Malheureusement, il s'agit d'une opération d'interface graphique et pas nécessairement facilement scriptable.)
Si vous avez un appareil photo qui produit nativement la version 1.2 de DNG, c'est encore mieux, car cela inclut une somme de contrôle MD5 intégrée des données d'image. Malheureusement, cela ne semble pas être stocké avec les métadonnées d'image normales - ou au moins exiftool et exiv2 ne le reconnaissent pas, et ils lisent les fichiers 1.2 DNG en général - ce qui signifie que, pour autant que je sache actuellement, la validation Adobe outil est le seul moyen de profiter de cela aussi.
ImageVerifier a fait ce que vous vouliez. Malheureusement, il n'est plus disponible au téléchargement et le support a été interrompu le 31 décembre 2017 (voir Ingestamatic et ImageVerifier ne sont plus en vente ).
ImageVerifier (IV pour faire court) traverse une hiérarchie de dossiers à la recherche de fichiers image à vérifier. Il peut vérifier les TIFF, JPEG. PSD, DNG et matières premières non DNG (par exemple NEF, CR2).
IV est conçu pour traiter un grand nombre d'images. Les hiérarchies de dossiers avec 100 000 images ou plus ne devraient pas poser de problème. Dans un essai, IV a fonctionné pendant 14 heures.
Il existe deux types de vérification qu'IV effectue: la vérification de la structure et la vérification du hachage.
S'il ne s'agit pas de télécharger des images depuis votre appareil photo, mais d'un transfert d'ordinateur à ordinateur, une approche courante de l'intégrité des fichiers est la somme de contrôle .
Malheureusement, pour autant que je sache, les formats d'image "utilisateur final" courants (jpeg, png, gif,…) ne sont pas vérifiés par eux-mêmes. Mais si je comprends bien la question d'impliquer un traitement automatisé, l'intégration d'outils de somme de contrôle ( CRC32 , MD5 ,…) dans le flux de travail pourrait être une solution viable. Une approche commune pour stocker la somme de contrôle est d'avoir un fichier avec le même nom, juste avec une extension supplémentaire, comme: img123.jpg → img123.jpg.md5.
Cette approche présente l'avantage supplémentaire que vous pouvez également vérifier l'intégrité (par exemple) des fichiers side-car ou de tout autre élément que vous souhaitez transférer dans un mécanisme similaire. Et si vous conservez les fichiers de somme de contrôle, même à l'avenir. (Et il a l'inconvénient de ne pas être intégré dans PS, LR ou les autres outils courants dans la mesure de mes connaissances limitées.)
J'ai développé check_media_integrity un simple script python check_mi.py, vous pouvez le télécharger depuis GitHub:
https://github.com/ftarlao/check-media-integrity
Je cite l'intro du guide:
check-mi est un script Python 2.7 qui vérifie automatiquement l'intégrité des fichiers multimédias (images, vidéo, audio). Vous pouvez vérifier l'intégrité d'un seul fichier ou d'un ensemble de fichiers dans un dossier et des sous-dossiers de manière récursive, enfin vous pouvez éventuellement afficher la liste des fichiers incorrects avec leur chemin et leurs détails au format CSV.
L'outil teste l'intégrité des fichiers à l'aide de bibliothèques communes (Pillow, ImageMagik, FFmpeg) et vérifie s'ils sont effectivement capables de décoder les fichiers multimédias. Les formats d'avertissement, d'image, audio et vidéo sont très résistants aux défauts et dommages pour cette raison, l'outil ne peut pas détecter tous les fichiers endommagés.
check-mi est capable, avec une confiance de 100%, de repérer les fichiers qui ont des en-têtes / métadonnées cassés, des fichiers d'image tronqués (avec strict_level> 0) et des erreurs d'E / S de périphérique.
check-mi n'est généralement pas en mesure de détecter tous les dommages mineurs - par exemple, une petite partie du fichier multimédia écrasée avec des valeurs différentes. En détail, j'ai testé strict_level 1 avec une petite expérience randomisée, exécutée sur une seule image jpeg de 5 Mo:
En écrasant une partie (intervalle) du fichier image avec des zéros, vous avez besoin d'une taille d'intervalle = 1024 Ko pour obtenir 50% de chances de détecter les dommages. En écrasant une partie (intervalle) du fichier image avec différentes valeurs aléatoires, vous obtenez un taux de détection d'environ 85%, pour des tailles d'intervalle allant de 4096 octets à 1024 Ko.
Dans le cas où vous savez comment demander à Pillow, Wand et FFmpeg d'être plus stricts lors du décodage, veuillez me le dire.
La réponse acceptée fait référence à l'utilisation de jpeginfo, qui est un outil vraiment ancien et non maintenu écrit en C (et aussi pas très modulaire / extensible). En outre, cet outil semble simplement rechercher des points de données EXIF spécifiques (parcourir le code source pendant environ 5 minutes).
IMO, un meilleur outil appelé type de fichier , est très facile à utiliser - en gros, copiez-collez leur exemple de code et modifiez le nom du fichier si vous ne savez pas comment coder. Il vérifie les nombres magiques associés à certains types de fichiers connus et vous permet de savoir quel type de fichier vous traitez.
Je cherche toujours plus de couches de protection que cela. Par exemple, si des données arbitraires sont stockées après (ou dans) les métadonnées EXIF, ou après les nombres magiques, cela peut poser des problèmes de sécurité. Je continuerai à examiner d'autres mesures de sécurité et j'espère mettre à jour cette réponse ultérieurement.
Voici l'exemple de code copié à partir de leur page Web, pour les paresseux:
// 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'}
Pour info, cet outil est constamment mis à jour (il y a 3 jours était la dernière mise à jour, à partir de ma réponse originale ici), et ils ont actuellement 3 691 850 téléchargements hebdomadaires - c'est donc probablement une bonne indication.
file(qui fonctionne de la même manière) rendra compte correctement, mais échouera au rendu car la plupart des données sont réellement manquantes.