Czasami, gdy pobierasz obraz, a połączenie przerywa się w połowie strumienia, masz do połowy pobrany obraz. Jeśli spróbujesz go wyświetlić, otrzymasz górną część obrazu, a dolna część jest zwykle w kolorze szarym lub zielonym lub innym kolorze. Innymi słowy, jest uszkodzony.
Czy istnieje sposób na sprawdzenie, czy obraz jest w ten sposób uszkodzony lub w inny sposób uszkodzony?
Odpowiedzi:
Jeśli mówisz o plikach JPEG, to narzędzie jpeginfo jest dokładnie tym, czego szukasz. Może sprawdzać pliki pod kątem różnego rodzaju błędów i uszkodzeń JPEG i albo zwrócić kod błędu (najbardziej przydatna rzecz dla skryptów), albo po prostu usunąć pliki z błędami.
Używam tego jako części mojego początkowego transferu plików, aby upewnić się, że wszystko jest w porządku, bez konieczności ręcznego sprawdzania. (Po tym upewniam się, że ich sumy kontrolne nie zmieniają się w ramach mojej normalnej ochrony kopii zapasowej / bitrotu.)
Program jest wierszem poleceń i jest dostarczany jako kod źródłowy, ale powinien być łatwy do zbudowania i używania w dowolnej dystrybucji Linuksa lub na komputerze Mac z poprawnie skonfigurowanym środowiskiem programistycznym. Jestem pewien, że możesz to zrobić nawet w systemie Windows z Cygwin lub MinGW. (Na przykład, chociaż nie mogę ręczyć za jego integralność, ten post na blogu wydaje się wiarygodny i zawiera wstępnie skompilowane pobieranie). Aby go zbudować:
$ git clone https://github.com/tjko/jpeginfo.git
Cloning into 'jpeginfo'...
[...]
Checking connectivity... done
$ cd jpeginfo/
$ ./configure && make
Powinno to utworzyć jpeginfopolecenie, które można uruchomić w miejscu lub skopiować w dowolnym miejscu (ewentualnie za pomocą make install).
Następnie uruchom to w następujący sposób:
$ ./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]
Tutaj test1.jpg jest całkowicie w porządku, a test2.jpg usunąłem kilka bajtów z końca, a test3.jpg zmieniłem kilka losowych bajtów w nagłówku.
Jeśli masz pliki RAW, sprawdź tę stronę Amerykańskiego Towarzystwa Fotografów Medialnych na temat walidacji DNG lub jedną ze szczegółowych informacji na temat walidacji danych , która obejmuje użycie konwertera DNG firmy Adobe do walidacji partii zastrzeżonych formatów RAW. (Niestety jest to operacja GUI i niekoniecznie łatwa do skryptowania).
Jeśli masz kamerę, która natywnie generuje wersję DNG 1.2, jest to nawet lepsze, ponieważ obejmuje ona wbudowaną sumę kontrolną MD5 danych obrazu. Niestety, wydaje się, że nie są one przechowywane z normalnymi metadanymi obrazu - lub przynajmniej exiftool i exiv2 nie rozpoznają go, i czytają ogólnie pliki DNG 1.2 - co oznacza, że o ile wiem obecnie walidację Adobe narzędzie to jedyny sposób, aby z tego skorzystać.
ImageVerifier zrobił to, co chciałeś. Niestety nie jest już dostępny do pobrania, a wsparcie zostało wycofane 31 grudnia 2017 r. (Zobacz Ingestamatic i ImageVerifier nie jest już w sprzedaży ).
ImageVerifier (w skrócie IV) przegląda hierarchię folderów szukających plików obrazów do weryfikacji. Może weryfikować TIFF, JPEG. PSD, DNG i surowce inne niż DNG (np. NEF, CR2).
IV przeznaczony jest do przetwarzania dużej liczby zdjęć. Hierarchie folderów zawierające 100 000 lub więcej obrazów nie powinny stanowić problemu. W jednym cyklu testowym IV prowadzono przez 14 godzin.
Istnieją dwa rodzaje weryfikacji, które wykonuje IV: Sprawdzanie struktury i sprawdzanie skrótu.
Jeśli nie chodzi o pobieranie zdjęć z aparatu, ale o transfer z komputera na komputer, powszechnym podejściem do integralności plików są sumy kontrolne .
Niestety, o ile mi wiadomo, popularne formaty obrazów „użytkownika końcowego” (jpeg, png, gif,…) nie są sprawdzane samodzielnie. Ale ponieważ rozumiem pytanie, które ma oznaczać zautomatyzowane przetwarzanie, integracja narzędzi sum kontrolnych ( CRC32 , MD5 ,…) w przepływie pracy może być realnym rozwiązaniem. Wspólne podejście do przechowywania sumę kontrolną ma mieć plik o tej samej nazwie pliku, tylko z dodanym rozszerzeniem, jak: img123.jpg → img123.jpg.md5.
Takie podejście ma tę dodatkową zaletę, że można również sprawdzić integralność (na przykład) plików sidecar lub cokolwiek innego, co chcesz przesłać w podobny mechanizm. A jeśli zachowasz pliki sum kontrolnych, nawet w przyszłości. (I ma tę wadę, że nie jest zintegrowany z PS, LR lub innymi popularnymi narzędziami, o ile mam ograniczoną wiedzę.)
Opracowałem check_media_integrity prosty skrypt w języku Python check_mi.py, który możesz pobrać z GitHub:
https://github.com/ftarlao/check-media-integrity
Cytuję wprowadzenie przewodnika:
check-mi to skrypt Python 2.7, który automatycznie sprawdza integralność plików multimedialnych (zdjęć, wideo, audio). Możesz sprawdzić integralność pojedynczego pliku lub zestawu plików w folderze i podfolderach rekurencyjnie, w końcu możesz opcjonalnie wypisać listę uszkodzonych plików wraz z ich ścieżką i szczegółami w formacie CSV.
Narzędzie testuje integralność plików przy użyciu popularnych bibliotek (Pillow, ImageMagik, FFmpeg) i sprawdza, czy są w stanie skutecznie dekodować pliki multimedialne. Formaty ostrzeżeń, obrazów, audio i wideo są bardzo odporne na wady i uszkodzenia, dlatego narzędzie nie może wykryć wszystkich uszkodzonych plików.
check-mi jest w stanie, ze 100% pewnością, wykryć pliki, które mają zepsuty nagłówek / metadane, obcięte pliki obrazów (z poziomem ścisłym> 0) i błędy we / wy urządzenia.
check-mi zwykle nie jest w stanie wykryć wszystkich drobnych uszkodzeń - np. mała część pliku multimedialnego zastąpiona różnymi wartościami. Szczegółowo przetestowałem strict_level 1 z małym randomizowanym eksperymentem, wykonanym na pojedynczym obrazie JPEG o wielkości 5 MB:
Nadpisując część (interwał) pliku obrazu zerami, potrzebujesz rozmiaru interwału = 1024 KB, aby uzyskać 50% szansy na wykrycie uszkodzenia. Nadpisując część (interwał) pliku obrazu różnymi losowymi wartościami, uzyskuje się współczynnik wykrywania około 85%, dla przedziałów wielkości od 4096 bajtów do 1024 kilobajtów.
W przypadku, gdy znasz sposoby na instrukcje Pillow, Wand i FFmpeg, aby były bardziej rygorystyczne podczas dekodowania, proszę powiedz mi.
Przyjęta odpowiedź dotyczy użycia jpeginfo, które jest naprawdę starym i nieobsługiwanym narzędziem napisanym w C (a także niezbyt modułowym / rozszerzalnym). Narzędzie to wydaje się po prostu szukać określonych punktów danych EXIF (przeglądaj kod źródłowy przez ~ 5 minut).
IMO, lepsze narzędzie o nazwie typ pliku , jest bardzo łatwe w użyciu - w zasadzie skopiuj-wklej ich przykładowy kod i zmodyfikuj nazwę pliku, jeśli nie wiesz, jak kodować. Sprawdza magiczne liczby związane z pewnymi znanymi typami plików i informuje, z jakim plikiem masz do czynienia.
Wciąż szukam więcej warstw ochrony niż tylko to. Na przykład, jeśli dowolne dane są przechowywane poza (lub wewnątrz) metadanymi EXIF lub po magicznych liczbach, które mogą stwarzać problemy bezpieczeństwa. Będę nadal szukał więcej środków bezpieczeństwa i mam nadzieję później zaktualizować tę odpowiedź.
Oto przykładowy kod skopiowany z ich strony internetowej dla leniwych:
// 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'}
Do Twojej wiadomości, to narzędzie jest stale aktualizowane (3 dni temu była ostatnią aktualizacją, zgodnie z moją pierwotną odpowiedzią tutaj), i obecnie mają one 3 691 850 pobrań tygodniowo - więc to prawdopodobnie dobra wskazówka.
filesą raportowane poprawnie przez POSIX (który działa w ten sam sposób), ale nie renderują, ponieważ w rzeczywistości brakuje wielu danych.