A veces, cuando descargas una imagen y la conexión se interrumpe a mitad de la transmisión, te quedas con una imagen medio descargada. Si intentas verlo, obtienes la parte superior de la imagen y la parte inferior suele ser de color gris o verde u otro color. En otras palabras, está corrompido.
¿Hay alguna manera de verificar si la imagen está dañada de esa manera o si está dañada?
Respuestas:
Si está hablando de archivos JPEG, entonces la utilidad jpeginfo es exactamente lo que está buscando. Puede verificar los archivos para detectar diferentes tipos de errores JPEG y corrupción y devolver un código de error (lo más útil para las secuencias de comandos) o simplemente eliminar archivos con errores.
Lo uso como parte de mi transferencia de archivos inicial, para asegurarme de que todo se haya copiado correctamente sin depender de la verificación manual. (Después de eso, me aseguro de que sus sumas de verificación no cambien como parte de mi protección normal de respaldo / bitrot).
El programa es de línea de comandos y viene como código fuente, pero debería ser fácil de construir y usar en cualquier distribución de Linux o en una Mac con un entorno de desarrollo configurado correctamente. Estoy seguro de que incluso podría hacerlo en Windows con Cygwin o MinGW. (Por ejemplo, aunque no puedo garantizar su integridad, esta publicación de blog parece legítima e incluye una descarga precompilada). Para construirlo usted mismo:
$ git clone https://github.com/tjko/jpeginfo.git
Cloning into 'jpeginfo'...
[...]
Checking connectivity... done
$ cd jpeginfo/
$ ./configure && make
Esto debería crear un jpeginfocomando que puede ejecutar en su lugar o copiar donde desee (posiblemente usando make install).
Luego, lo ejecutas así:
$ ./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]
Aquí, test1.jpg está perfectamente bien, y test2.jpg borré algunos bytes del final, y test3.jpg cambié algunos bytes aleatorios en el encabezado.
Si tiene archivos RAW, consulte esta página de la American Society of Media Photographers sobre Validación de DNG , o una sobre detalles de validación de datos , que cubre el uso del convertidor DNG de Adobe para validar por lotes formatos RAW patentados. (Desafortunadamente, esta es una operación de GUI y no necesariamente fácilmente programable).
Si tiene una cámara que genera de forma nativa la versión 1.2 de DNG, eso es aún mejor, ya que incluye una suma de comprobación MD5 incorporada de los datos de la imagen. Desafortunadamente, esto no parece estar almacenado con los metadatos de la imagen normal, o al menos exiftool y exiv2 no lo reconocen, y leen 1.2 archivos DNG en general, lo que significa que, hasta donde sé, actualmente la validación de Adobe la herramienta es la única forma de aprovechar eso también.
ImageVerifier hizo lo que querías. Desafortunadamente, ya no está disponible para descargar y el soporte se suspendió el 31 de diciembre de 2017 (consulte Ingestamatic e ImageVerifier ya no está a la venta ).
ImageVerifier (IV para abreviar) atraviesa una jerarquía de carpetas en busca de archivos de imagen para verificar. Puede verificar TIFF, JPEG. PSD, DNG y no-DNG raws (por ejemplo, NEF, CR2).
IV está diseñado para procesar grandes cantidades de imágenes. Las jerarquías de carpetas con 100,000 imágenes o más no deberían ser un problema. En una prueba, IV corrió durante 14 horas.
Hay dos tipos de verificación que realiza IV: verificación de estructura y verificación hash.
Si no se trata de descargar imágenes de su cámara, sino de una transferencia de computadora a computadora, un enfoque común para la integridad de los archivos son las sumas de verificación .
Desafortunadamente, hasta donde yo sé, los formatos de imagen comunes de "usuario final" (jpeg, png, gif, ...) no se verifican por sí solos. Pero, según tengo entendido, la cuestión de implicar un procesamiento automatizado, la integración de herramientas de suma de verificación ( CRC32 , MD5 , ...) en el flujo de trabajo podría ser una solución viable. Un enfoque común para almacenar la suma de control es tener un archivo con el mismo nombre de archivo, sólo con una extensión añadida, como: img123.jpg → img123.jpg.md5.
Este enfoque tiene el beneficio adicional de que también puede verificar la integridad de (por ejemplo) archivos de sidecar o cualquier otra cosa que desee transferir en un mecanismo similar. Y si mantiene los archivos de suma de comprobación, incluso en el futuro. (Y tiene el inconveniente de no estar integrado en PS, LR u otras herramientas comunes en la medida de mi conocimiento limitado).
Desarrollé check_media_integrity un simple script de Python check_mi.py, puedes descargarlo desde GitHub:
https://github.com/ftarlao/check-media-integrity
Cito la introducción de la guía:
check-mi es un script Python 2.7 que verifica automáticamente la integridad de los archivos multimedia (imágenes, video, audio). Puede verificar la integridad de un solo archivo, o un conjunto de archivos en una carpeta y subcarpetas de forma recursiva, finalmente, opcionalmente, puede generar la lista de archivos defectuosos con su ruta y detalles en formato CSV.
La herramienta prueba la integridad de los archivos utilizando bibliotecas comunes (Pillow, ImageMagik, FFmpeg) y verificando cuándo pueden decodificar efectivamente los archivos multimedia. Los formatos de advertencia, imagen, audio y video son muy resistentes a defectos y daños por esta razón la herramienta no puede detectar todos los archivos dañados.
check-mi es capaz, con 100% de confianza, de detectar archivos que tienen encabezado / metadatos rotos, archivos de imagen truncados (con nivel_stricto> 0) y errores de E / S del dispositivo.
check-mi, por lo general, no puede detectar todos los daños menores, por ejemplo, una pequeña parte del archivo multimedia sobrescrito con diferentes valores. En detalle, probé el nivel estricto 1 con un pequeño experimento aleatorio, ejecutado en una sola imagen JPEG de 5 MB:
Sobrescribiendo una porción (intervalo) del archivo de imagen con ceros, necesita un tamaño de intervalo = 1024KBytes para obtener un 50% de posibilidades de detectar el daño. Sobrescribiendo una porción (intervalo) de archivo de imagen con diferentes valores aleatorios, obtiene aproximadamente un 85% de relación de detección, para tamaños de intervalo que van desde 4096bytes hasta 1024Kbytes.
En el caso de que conozca maneras de indicarle a Pillow, Wand y FFmpeg que sean más estrictos al decodificar, por favor dígame.
La respuesta aceptada se refiere al uso de jpeginfo, que es una herramienta realmente antigua y no mantenida escrita en C (y tampoco muy modular / extensible). Además, esa herramienta parece solo buscar algunos puntos de datos EXIF específicos (hojear el código fuente durante ~ 5 minutos).
IMO, una mejor herramienta llamada tipo de archivo , es muy fácil de usar: básicamente copie y pegue su código de ejemplo y modifique el nombre del archivo si no sabe cómo codificar. Comprueba los números mágicos asociados con ciertos tipos de archivos conocidos y le permite saber con qué tipo de archivo está tratando.
Todavía estoy buscando más capas de protección que solo esto. Por ejemplo, si los datos arbitrarios se almacenan más allá (o en) los metadatos EXIF, o después de los números mágicos, eso puede plantear problemas de seguridad. Continuaré buscando más medidas de seguridad y espero actualizar esta respuesta más tarde.
Aquí está el código de ejemplo copiado de su página web, para los perezosos:
// 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'}
Para su información, esta herramienta se actualiza constantemente (hace 3 días era la última actualización, a partir de mi respuesta original aquí), y actualmente tienen 3.691.850 descargas semanales, por lo que probablemente sea una buena indicación.
file(que funciona de la misma manera) informará correctamente, pero no se procesará porque faltan muchos de los datos.