Às vezes, quando você está baixando uma imagem e a conexão interrompe o fluxo médio, você fica com uma imagem baixada pela metade. Ao tentar visualizá-lo, você obtém a parte superior da imagem e a parte inferior geralmente é cinza ou verde ou outra cor. Em outras palavras, ele está corrompido.
Existe uma maneira de verificar se a imagem está danificada dessa maneira ou está corrompida?
Respostas:
Se você está falando sobre arquivos JPEG, o utilitário jpeginfo é exatamente o que você está procurando. Ele pode verificar os arquivos em busca de diferentes tipos de erros e corrupção de JPEG e retornar um código de erro (a coisa mais útil para scripts) ou apenas excluir arquivos com erros.
Eu uso isso como parte da minha transferência inicial de arquivos, para garantir que tudo seja copiado corretamente, sem depender da verificação manual. (Depois disso, garanto que as somas de verificação não sejam alteradas como parte da minha proteção normal de backup / bitrot.)
O programa é de linha de comando e vem como código-fonte, mas deve ser fácil criar e usar em qualquer distribuição Linux ou em um Mac com um ambiente de desenvolvimento configurado corretamente. Tenho certeza que você pode fazê-lo no Windows com Cygwin ou MinGW. (Por exemplo, embora eu não possa garantir sua integridade, esta postagem no blog parece legítima e inclui um download pré-compilado.) Para criar você mesmo:
$ git clone https://github.com/tjko/jpeginfo.git
Cloning into 'jpeginfo'...
[...]
Checking connectivity... done
$ cd jpeginfo/
$ ./configure && make
Isso deve criar um jpeginfocomando que você pode executar no local ou copiar onde quiser (possivelmente usando make install).
Em seguida, execute-o assim:
$ ./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]
Aqui, test1.jpg está perfeitamente bem, e test2.jpg excluí alguns bytes do final e test3.jpg alterei alguns bytes aleatórios no cabeçalho.
Se você tiver arquivos RAW, consulte esta página da Sociedade Americana de Fotógrafos de Mídia sobre Validação DNG , ou uma sobre detalhes de validação de dados , que abrange o uso do conversor DNG da Adobe para validar lotes de formatos RAW proprietários. (Infelizmente, esta é uma operação da GUI e não é necessariamente fácil de criar um script.)
Se você possui uma câmera que produz nativamente a versão 1.2 do DNG, isso é ainda melhor, pois isso inclui uma soma de verificação MD5 incorporada dos dados da imagem. Infelizmente, isso não parece ser armazenado com os metadados normais da imagem - ou pelo menos o exiftool e o exiv2 não o reconhecem e eles leem 1.2 arquivos DNG em geral - o que significa que, até onde sei, atualmente a validação da Adobe ferramenta é a única maneira de tirar proveito disso também.
O ImageVerifier fez o que você queria. Infelizmente, ele não está mais disponível para download e o suporte foi descontinuado em 31 de dezembro de 2017 (consulte Ingestamatic e ImageVerifier não estão mais à venda ).
O ImageVerifier (IV abreviado) percorre uma hierarquia de pastas procurando arquivos de imagem para verificar. Pode verificar TIFFs, JPEGs. PSDs, DNGs e matérias-primas não DNG (por exemplo, NEF, CR2).
O IV foi projetado para processar um grande número de imagens. Hierarquias de pastas com 100.000 imagens ou mais não devem ser problema. Em uma execução de teste, o IV foi executado por 14 horas.
Existem dois tipos de verificação que o IV executa: Verificação de estrutura e verificação de hash.
Se não se trata de baixar imagens da sua câmera, mas de uma transferência de computador para computador, uma abordagem comum à integridade dos arquivos são somas de verificação .
Infelizmente, até onde eu sei, os formatos de imagem comuns de "usuário final" (jpeg, png, gif, ...) não são verificados por si próprios. Porém, como eu entendo a questão como implicando processamento automatizado, integrar ferramentas de soma de verificação ( CRC32 , MD5 ,…) ao fluxo de trabalho pode ser uma solução viável. Uma abordagem comum para armazenar a soma de verificação é ter um arquivo com o mesmo nome, apenas com uma extensão adicional, como: img123.jpg → img123.jpg.md5.
Essa abordagem tem o benefício adicional de que você também pode verificar a integridade de (por exemplo) arquivos sidecar ou qualquer outra coisa que queira transferir em um mecanismo semelhante. E se você mantiver os arquivos da soma de verificação por perto, mesmo no futuro. (E tem a desvantagem de não estar integrado ao PS, LR ou a outras ferramentas comuns, na medida do meu conhecimento limitado.)
Eu desenvolvi check_media_integrity um script python simples check_mi.py, você pode baixá-lo no GitHub:
https://github.com/ftarlao/check-media-integrity
Cito a introdução do guia:
check-mi é um script Python 2.7 que verifica automaticamente a integridade dos arquivos de mídia (fotos, vídeo, áudio). Você pode verificar a integridade de um único arquivo ou conjunto de arquivos em uma pasta e subpastas recursivamente. Finalmente, você pode opcionalmente exibir a lista de arquivos incorretos com o caminho e os detalhes no formato CSV.
A ferramenta testa a integridade dos arquivos usando bibliotecas comuns (Pillow, ImageMagik, FFmpeg) e verificando quando eles conseguem efetivamente decodificar os arquivos de mídia. Os formatos de aviso, imagem, áudio e vídeo são muito resistentes a defeitos e danos; por esse motivo, a ferramenta não pode detectar todos os arquivos danificados.
O check-mi é capaz, com 100% de confiança, de detectar arquivos com cabeçalho / metadados quebrados, arquivos de imagem truncados (com nível de estrito> 0) e erros de E / S do dispositivo.
O check-mi geralmente não é capaz de detectar todos os danos menores - por exemplo, pequena parte do arquivo de mídia substituída por valores diferentes. Em detalhes, testei o strict_level 1 com um pequeno experimento aleatório, executado em uma única imagem jpeg de 5 MB:
Sobrescrevendo uma parte (intervalo) do arquivo de imagem com zeros, você precisa do tamanho do intervalo = 1024KBytes para obter 50% de chance de detectar o dano. Sobrescrevendo uma parte (intervalo) do arquivo de imagem com diferentes valores aleatórios, você obtém uma taxa de detecção de cerca de 85%, para tamanhos de intervalo que variam de 4096 bytes a 1024 KB.
No caso de você saber maneiras de instruir Pillow, Wand e FFmpeg a serem mais rígidos ao decodificar, me diga.
A resposta aceita refere-se ao uso do jpeginfo, que é uma ferramenta realmente antiga e não mantida, escrita em C (e também não muito modular / extensível). Além disso, essa ferramenta parece apenas procurar alguns pontos de dados EXIF específicos (percorra o código-fonte por ~ 5 minutos).
O IMO, uma ferramenta melhor chamada tipo de arquivo , é muito fácil de usar - basicamente copie e cole o código de exemplo e modifique o nome do arquivo se você não souber codificar. Ele verifica os números mágicos associados a certos tipos de arquivos conhecidos e permite saber com que tipo de arquivo você está lidando.
Ainda estou procurando por mais camadas de proteção do que apenas isso. Por exemplo, se dados arbitrários são armazenados após (ou dentro) dos metadados EXIF, ou após os números mágicos, isso pode causar problemas de segurança. Continuarei analisando mais medidas de segurança e espero atualizar mais tarde esta resposta.
Aqui está o código de exemplo copiado de sua página da Web, para os preguiçosos:
// 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'}
Para sua informação, esta ferramenta está sendo constantemente atualizada (há 3 dias foi a última atualização, como na minha resposta original aqui), e atualmente eles têm 3.691.850 downloads semanais - então essa é provavelmente uma boa indicação.
file(que opera da mesma maneira) reportará corretamente, mas falhará na renderização porque muitos dados estão realmente ausentes.