Есть ли инструмент для проверки целостности файлов серии изображений?

Иногда, когда вы загружаете изображение, и соединение разрывается в середине потока, у вас остается половина загруженного изображения. Если вы попытаетесь просмотреть его, вы получите верхнюю часть изображения, а нижняя часть обычно окрашена в серый, зеленый или другой цвет. Другими словами, он поврежден.

Есть ли способ проверить, повреждено ли изображение таким образом или иным образом повреждено?

Если вы говорите о файлах JPEG, то утилита jpeginfo именно то, что вы ищете. Он может проверять файлы на наличие различных типов ошибок JPEG и повреждений и либо возвращать код ошибки (наиболее полезная вещь для сценариев), либо просто удалять файлы с ошибками.

Я использую это как часть моей первоначальной передачи файлов, чтобы убедиться, что все скопировано нормально, не полагаясь на ручную проверку. (После этого я проверяю, чтобы их контрольные суммы не менялись, как часть моей обычной защиты от резервного копирования / битрота.)

Программа является командной строкой и поставляется в виде исходного кода, но ее должно быть легко собрать и использовать в любом дистрибутиве Linux или на Mac с правильно настроенной средой разработки. Я уверен, что вы могли бы даже сделать это на Windows с Cygwin или MinGW. (Например, хотя я не могу ручаться за его целостность, этот пост в блоге кажется законным и включает в себя предварительно скомпилированную загрузку.) Чтобы создать его самостоятельно:

$ git clone https://github.com/tjko/jpeginfo.git
Cloning into 'jpeginfo'...
[...]
Checking connectivity... done
$ cd jpeginfo/
$ ./configure && make

Это должно создать jpeginfoкоманду, которую вы можете запустить на месте или скопировать в любое место (возможно, используя make install).

Затем вы запускаете это так:

$ ./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]

Здесь test1.jpg отлично подходит, и test2.jpg Я удалил несколько байтов с конца, а test3.jpg Я изменил несколько случайных байтов в заголовке.

Если у вас есть файлы RAW, ознакомьтесь с этой страницей в Американском обществе медиа-фотографов , посвященной проверке DNG , или страницей , посвященной проверке данных , в которой описано использование DNG-конвертера Adobe для пакетной проверки проприетарных форматов RAW. (К сожалению, это операция с графическим интерфейсом, которая не обязательно легко скриптируется.)

Если у вас есть камера, которая изначально выводит версию DNG 1.2, это даже лучше, поскольку она включает в себя встроенную контрольную сумму MD5 данных изображения. К сожалению, это, кажется, не хранится с обычными метаданными изображения - или, по крайней мере, exiftool и exiv2 не распознают его, и они вообще читают файлы 1.2 DNG - это означает, что, насколько я знаю, в настоящее время проверка Adobe инструмент - единственный способ воспользоваться этим тоже.

ImageVerifier сделал то, что вы хотели. К сожалению, он больше не доступен для загрузки, и поддержка была прекращена 31 декабря 2017 года (см. Ingestamatic и ImageVerifier больше не продаются ).

Старый ответ по историческим причинам

ImageVerifier (для краткости IV) пересекает иерархию папок, ища файлы изображений для проверки. Это может проверить TIFFs, JPEG. PSD, DNG и не-DNG необработанные (например, NEF, CR2).

IV предназначен для обработки большого количества изображений. Иерархии папок с 100 000 изображений или более должны быть без проблем. В одном тестовом прогоне IV работал в течение 14 часов.

Существует два вида проверки, которую выполняет IV: проверка структуры и проверка хеша.

http://basepath.com/site/detail-ImageVerifier.php

Если речь идет не о загрузке изображений с камеры, а о передаче с компьютера на компьютер, общий подход к целостности файлов - это контрольные суммы .

К сожалению, насколько мне известно, обычные форматы изображений «конечного пользователя» (jpeg, png, gif,…) сами по себе не проверяются на целостность. Но, как я понимаю вопрос, подразумевающий автоматическую обработку, интеграция инструментов контрольной суммы ( CRC32 , MD5 ,…) в рабочий процесс может быть жизнеспособным решением. Общий подход для хранения контрольной суммы должна иметь файл с тем же именем, только с добавленным расширением, например: img123.jpg → img123.jpg.md5.

Этот подход имеет дополнительное преимущество, заключающееся в том, что вы также можете проверять целостность (например) файлов коляски или чего-либо еще, что вы хотите передать в аналогичном механизме. И если вы будете хранить файлы контрольных сумм даже в будущем. (И его недостатком является то, что я не интегрирован в PS, LR или другие распространенные инструменты, насколько мне известно.)

Я разработал check_media_integrity простой скрипт на Python check_mi.py, вы можете скачать его с GitHub:

https://github.com/ftarlao/check-media-integrity

Я цитирую вводное руководство:

check-mi - это скрипт на Python 2.7, который автоматически проверяет целостность медиа-файлов (изображений, видео, аудио). Вы можете проверить целостность отдельного файла или набора файлов в папке и подпапках рекурсивно, наконец, вы можете при желании вывести список поврежденных файлов с их путем и подробностями в формате CSV.

Инструмент проверяет целостность файлов, используя общие библиотеки (Pillow, ImageMagik, FFmpeg) и проверяя, способны ли они эффективно декодировать медиа-файлы. Предупреждение, форматы изображений, аудио и видео очень устойчивы к дефектам и повреждениям, поэтому инструмент не может обнаружить все поврежденные файлы.

check-mi может, со 100% -ной достоверностью, обнаруживать файлы с поврежденными заголовками / метаданными, усеченными файлами изображений (со строгим_уровнем> 0) и ошибками ввода-вывода устройства.

check-mi, как правило, не в состоянии обнаружить все незначительные повреждения - например, небольшая часть медиафайла, перезаписанная другими значениями. Подробно я протестировал strict_level 1 с небольшим рандомизированным экспериментом, выполненным на одной 5-мегабайтной картинке JPEG:

Перезаписывая часть (интервал) файла изображения нулями, вам нужен интервал size = 1024KBytes, чтобы получить 50% -ную вероятность обнаружения повреждения. Перезаписывая часть (интервал) файла изображения различными случайными значениями, вы получите коэффициент обнаружения около 85% для интервалов размером от 4096 байт до 1024 Кбайт.

В случае, если вы знаете, как инструктировать Pillow, Wand и FFmpeg, чтобы быть более строгими при декодировании, пожалуйста, сообщите мне.

Принятый ответ относится к использованию jpeginfo, который является действительно старым и необслуживаемым инструментом, написанным на C (а также не очень модульным / расширяемым). Кроме того, этот инструмент, кажется, просто ищет некоторые конкретные точки данных EXIF ​​(просматривайте исходный код в течение ~ 5 минут).

IMO, лучший инструмент с именем file-type , очень прост в использовании - в основном скопируйте и вставьте его пример кода и измените имя файла, если вы не знаете, как кодировать. Он проверяет магические числа, связанные с определенными известными типами файлов, и позволяет узнать, с каким файлом вы имеете дело.

Я все еще ищу больше слоев защиты, чем просто это. Например, если произвольные данные хранятся после (или в) метаданных EXIF ​​или после магических чисел, это может создать проблемы безопасности. Я продолжу изучать дополнительные меры безопасности и надеюсь позже обновить этот ответ.

Вот пример кода, скопированного с их веб-страницы, для ленивых:

// 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'}

К вашему сведению, этот инструмент постоянно обновляется (3 дня назад было последним обновлением, так как мой первоначальный ответ здесь), и в настоящее время у него есть 3 691 850 загрузок в неделю - так что это, вероятно, хороший показатель.