A volte quando scarichi un'immagine e la connessione si interrompe a metà flusso, ti rimane un'immagine scaricata per metà. Se si tenta di visualizzarlo, si ottiene la parte superiore dell'immagine e la parte inferiore di solito è colorata in grigio o verde o in qualche altro colore. In altre parole, è danneggiato.
C'è un modo per verificare se l'immagine è danneggiata in quel modo o altrimenti corrotta?
Risposte:
Se stai parlando di file JPEG, l'utilità jpeginfo è esattamente quello che stai cercando. Può controllare i file per diversi tipi di errori JPEG e corruzione e può restituire un codice di errore (la cosa più utile per lo scripting) o semplicemente eliminare i file con errori.
Lo uso come parte del mio trasferimento iniziale di file, per essere sicuro che tutto sia stato copiato senza fare affidamento sul controllo manuale. (Successivamente, mi assicuro che i loro checksum non cambino come parte della mia normale protezione di backup / bitrot.)
Il programma è a riga di comando e viene fornito come codice sorgente, ma dovrebbe essere facile da compilare e utilizzare su qualsiasi distribuzione Linux o su un Mac con un ambiente di sviluppo impostato correttamente. Sono sicuro che potresti persino farlo su Windows con Cygwin o MinGW. (Ad esempio, anche se non posso garantire la sua integrità, questo post sul blog sembra legittimo e include un download precompilato.) Per crearlo tu stesso:
$ git clone https://github.com/tjko/jpeginfo.git
Cloning into 'jpeginfo'...
[...]
Checking connectivity... done
$ cd jpeginfo/
$ ./configure && make
Questo dovrebbe creare un jpeginfocomando che puoi eseguire sul posto o copiare dove vuoi (possibilmente usando make install).
Quindi, lo esegui in questo modo:
$ ./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]
Qui test1.jpg va benissimo e test2.jpg ho eliminato alcuni byte dalla fine e test3.jpg ho cambiato alcuni byte casuali nell'intestazione.
Se disponi di file RAW, consulta questa pagina dell'American Society of Media Photographers su DNG Validation o uno sui dettagli di convalida dei dati , che copre l'uso del convertitore DNG di Adobe per convalidare in batch i formati RAW proprietari. (Sfortunatamente, si tratta di un'operazione GUI e non necessariamente facilmente gestibile da script.)
Se hai una videocamera che genera nativamente la versione 1.2 di DNG, è ancora meglio, in quanto include un checksum MD5 incorporato dei dati dell'immagine. Sfortunatamente, questo non sembra essere memorizzato con i normali metadati dell'immagine - o almeno exiftool ed exiv2 non lo riconoscono e leggono i file DNG 1.2 in generale - il che significa che per quanto ne so attualmente la convalida Adobe lo strumento è l'unico modo per trarne vantaggio.
ImageVerifier ha fatto quello che volevi. Purtroppo non è più disponibile per il download e il supporto è stato interrotto il 31 dicembre 2017 (consultare Ingestamatic e ImageVerifier non più in vendita ).
ImageVerifier (in breve IV) attraversa una gerarchia di cartelle in cerca di file immagine da verificare. Può verificare TIFF, JPEG. PSD, DNG e raw non DNG (ad es. NEF, CR2).
IV è progettato per elaborare un gran numero di immagini. Le gerarchie di cartelle con almeno 100.000 immagini non dovrebbero essere un problema. In una prova, IV ha funzionato per 14 ore.
Esistono due tipi di verifica che IV esegue: controllo della struttura e controllo dell'hash.
Se non si tratta di scaricare immagini dalla fotocamera, ma di un trasferimento da computer a computer, un approccio comune all'integrità dei file sono i checksum .
Sfortunatamente, per quanto ne so, i formati di immagine "utente finale" comuni (jpeg, png, gif, ...) non sono controllati da soli. Ma poiché capisco la domanda di implicare l'elaborazione automatizzata, l'integrazione di strumenti di checksum ( CRC32 , MD5 , ...) nel flusso di lavoro potrebbe essere una soluzione praticabile. Un approccio comune per memorizzare la somma di controllo è quello di avere un file con lo stesso nome, solo con un'estensione aggiunta, come: img123.jpg → img123.jpg.md5.
Questo approccio ha l'ulteriore vantaggio di poter anche controllare l'integrità dei file sidecar (ad esempio) o qualsiasi altra cosa che si desidera trasferire in un meccanismo simile. E se tieni i file di checksum in giro, anche in futuro. (E ha il rovescio della medaglia di non essere integrato in PS, LR o altri strumenti comuni nella misura della mia conoscenza limitata.)
Ho sviluppato check_media_integrity un semplice script Python check_mi.py, puoi scaricarlo da GitHub:
https://github.com/ftarlao/check-media-integrity
Cito l'intro guida:
check-mi è uno script Python 2.7 che controlla automaticamente l'integrità dei file multimediali (immagini, video, audio). Puoi verificare l'integrità di un singolo file o un set di file in una cartella e sottocartelle in modo ricorsivo, infine puoi facoltativamente generare l'elenco di file danneggiati con il loro percorso e dettagli in formato CSV.
Lo strumento verifica l'integrità dei file utilizzando le librerie comuni (Pillow, ImageMagik, FFmpeg) e verificando quando sono effettivamente in grado di decodificare i file multimediali. I formati di avviso, immagine, audio e video sono molto resistenti ai difetti e ai danni, per questo motivo lo strumento non è in grado di rilevare tutti i file danneggiati.
check-mi è in grado, con la sicurezza del 100%, di individuare file con intestazione / metadati rotti, file di immagine troncati (con livello_del_pieno> 0) ed errori di I / O del dispositivo.
check-mi, di solito, non è in grado di rilevare tutti i danni minori, ad esempio una piccola porzione di file multimediale sovrascritta con valori diversi. In dettaglio, ho testato rigor_level 1 con un piccolo esperimento randomizzato, eseguito su una singola immagine jpeg da 5 MB:
Sovrascrivendo una porzione (intervallo) di file immagine con zeri, è necessario un intervallo di dimensioni = 1024 KB per ottenere il 50% di probabilità di rilevare il danno. Sovrascrivendo una porzione (intervallo) di file immagine con diversi valori casuali, si ottiene un rapporto di rilevamento di circa l'85%, per intervalli che vanno da 4096 byte a 1024 KB.
Nel caso in cui tu sappia come istruire Pillow, Wand e FFmpeg a essere più severi durante la decodifica, per favore dimmelo.
La risposta accettata si riferisce all'uso di jpeginfo, che è uno strumento davvero vecchio e non gestito scritto in C (e anche non molto modulare / estensibile). Inoltre, quello strumento sembra solo cercare alcuni punti dati EXIF specifici (scorrere il codice sorgente per ~ 5 minuti).
IMO, uno strumento migliore chiamato tipo file , è molto facile da usare: sostanzialmente copia e incolla il loro codice di esempio e modifica il nome del file se non sai come codificare. Controlla i numeri magici associati a determinati tipi di file noti e ti consente di sapere con quale tipo di file hai a che fare.
Sto ancora cercando più livelli di protezione oltre a questo. Ad esempio, se i dati arbitrari vengono archiviati oltre (o dentro) i metadati EXIF o dopo i numeri magici, ciò può comportare problemi di sicurezza. Continuerò a esaminare ulteriori misure di sicurezza e spero di aggiornare successivamente questa risposta.
Ecco il codice di esempio copiato dalla loro pagina web, per i pigri:
// 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'}
Cordiali saluti, questo strumento viene costantemente aggiornato (3 giorni fa era l'ultimo aggiornamento, a partire dalla mia risposta originale qui), e attualmente hanno 3.691.850 download settimanali - quindi questa è probabilmente una buona indicazione.
file(che funziona nello stesso modo) riporti correttamente, ma non riesca a eseguire il rendering perché molti dei dati sono effettivamente mancanti.