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

21

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

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

ладья
источник

Ответы:

15

Если вы говорите о файлах 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 инструмент - единственный способ воспользоваться этим тоже.

mattdm
источник
Вы знаете, существуют ли бинарные файлы Windows для jpeginfo?
Ладья
1
Использование утилиты jpeginfo от git clone в Windows кажется невозможным, поскольку «aux» представляется зарезервированным именем Windows, и git не может клонировать вышеупомянутый каталог в существование.
Ладья
--- возобновить разговор с другого поста здесь; Распаковка архива выдает ошибку из-за 'aux'. Переименование «aux» в архиве помогло распаковать архив, а затем переименовать его в «aux» в cygwin решило эту проблему. Но запуск make из cygwin все еще приводил к многочисленным ошибкам; кое-что о wrjpgcom.c: 87: 54: предупреждение: несовместимое неявное объявление встроенной функции 'exit' [включено по умолчанию] #define ERREXIT (msg) (fprintf (stderr, "% s \ n", msg), выход (EXIT_FAILURE)) (только один из многих)
Ладья
@ldigas Я создал бинарный файл MinGW, который вы можете найти по адресу mattdm.org/misc/jpeginfo-w32/jpeginfo.exe . Я построил это на Linux , как кросс-скомпилированный исполняемый файл, поэтому не проверял, но , казалось, построить хорошо. Я не могу обещать, что это работает, но я обещаю, что это просто исходный код, в котором нет вирусов или чего-то еще. :)
mattdm
Подтвердил это несколько минут назад за усилия, которые вы предпринимаете, но, похоже, он не очень хорошо работает в Windows. jpeginfo -c any_jpeg_file.jpg Я предоставляю его, кажется, сообщает о преждевременном конце файла JPEG. Поток данных JPEG не содержит изображения [ОШИБКА].
Ладья
2

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

Кез
источник
Похоже, вы связаны с ImageVerifier, если так, не могли бы вы раскрыть это в своем ответе.
проклятые истины
1
Я не связан с продуктом вообще. Я должен был проверить некоторые файлы изображений после сбоя NAS и использовал этот инструмент. Я просто вырезал вставленный текст с сайта, чтобы дать описание.
Кез
FWIW - подходит для файлов камеры (jpgs и различные форматы RAW - основное предназначение), но не очень подходит для файлов других типов без кодеков и т. Д. Функция -identify ImageMagick - это еще один вариант
Kez
1

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

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

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

Корнелий
источник
1
Стоит отметить, что DNG содержит контрольную сумму и может быть проверена непосредственно в Lightroom.
Хампус Нильссон
Я не знал об этом! Отлично. Имеет смысл тоже. Я отредактировал ответ, чтобы прояснить, что я нацелен на форматы «конечного пользователя» больше, чем архивные форматы, хотя приятно, что DNG помогает с контрольными суммами.
Корнелиус
Я использую «Advanced Checksum Verifier» (ACSV) Ирниса Халиуллина, чтобы вычислить файлы контрольных сумм MD5, которые копируются на резервный носитель вместе с исходными файлами. ACSV работает в пакетном или интерактивном режиме. Целостность копии может быть проверена в любое время путем пересчета контрольной суммы и сравнения с оригиналом.
Пьер
1

Я разработал 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, чтобы быть более строгими при декодировании, пожалуйста, сообщите мне.

Фабиано Тарлао
источник
0

Принятый ответ относится к использованию 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 загрузок в неделю - так что это, вероятно, хороший показатель.

user3773048
источник
Типичные идентификаторы типов файлов, основанные на магических числах, обычно просто фокусируются на первых n байтах, поэтому это может не помочь с частично зафиксированным файлом изображения, который является основой вопроса, поставленного здесь. То есть, очень распространено наличие JPEG или PNG, о которых POSIX file(который работает таким же образом) будет сообщать правильно, но не сможет отобразить, потому что большая часть данных фактически отсутствует.