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

Іноді, коли ви завантажуєте зображення, а з'єднання розривається середнього потоку, у вас залишається половина завантаженого зображення. Якщо ви спробуєте переглянути його, ви отримаєте верхню частину зображення, а нижню частину зазвичай забарвлюють у сірий або зелений або інший колір. Іншими словами, він зіпсований.

Чи є спосіб перевірити, чи зображення таким чином пошкоджене чи пошкоджено іншим чином?

Якщо ви говорите про файли 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. (На жаль, це операція з графічним інтерфейсом і не обов'язково легко писати сценарій.)

Якщо у вас є камера, яка виводить 1.2 версію DNG, це ще краще, оскільки це включає вбудовану контрольну суму даних даних MD5. На жаль, це, здається, не зберігається з нормальними метаданими зображення - або, принаймні, exiftool і exiv2 не розпізнають їх, і вони взагалі читають 1,2 DNG-файли - це означає, що наскільки я зараз знаю перевірку Adobe Інструмент - єдиний спосіб скористатися цим.

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

Стара відповідь з історичних причин

ImageVerifier (коротко IV) проходить ієрархію папок, шукаючи файли зображень для перевірки. Він може перевірити TIFF, 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, як правило, не в змозі виявити всі незначні пошкодження - наприклад, невелика частина мультимедійного файлу перезаписана різними значеннями. Докладно я перевірив строгий_рівень 1 з невеликим рандомізованим експериментом, виконаним на одній картинці jpeg 5 Мб:

Переписуючи частину (інтервал) файлу зображення з нулями, вам потрібен розмір інтервалу = 1024 КБ, щоб отримати 50% шанс виявити шкоду. Перезаписуючи частину (інтервал) файлу зображення з різними випадковими значеннями, ви отримуєте близько 85% коефіцієнта виявлення для розмірів інтервалів від 4096 байт до 1024 Кбайт.

Якщо ви знаєте способи доручити Подушці, Паличці та FFmpeg бути більш жорсткими при розшифровці, будь ласка, скажіть мені.

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

IMO, кращий інструмент, який називається, тип файлу , дуже простий у використанні - в основному скопіюйте їх в прикладний код і змініть ім'я файлу, якщо ви не знаєте, як кодувати. Він перевіряє магічні цифри, пов’язані з певними відомими типами файлів, і дозволяє вам знати, з яким файлом ви маєте справу.

Я все ще шукаю більше шарів захисту, ніж тільки цей. Наприклад, якщо довільні дані зберігаються минулі (або в) метадані 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'}

FYI, цей інструмент постійно оновлюється (3 дні тому було останнім оновленням, на мою оригінальну відповідь тут), і на даний момент у них завантажено 3 691 850 тижневих завантажень - тож це, мабуть, хороший показник.