Rook
2014-01-15 01:51:53 UTC
有時，當您下載圖像時，如果連接中斷，您將剩下一半的圖像下載。如果嘗試查看它，則會得到圖像的上部，而下部通常是灰色或綠色或其他某種顏色。換句話說，它已損壞。
是否可以檢查圖像是否已通過這種方式損壞或以其他方式損壞？
有時，當您下載圖像時，如果連接中斷，您將剩下一半的圖像下載。如果嘗試查看它，則會得到圖像的上部，而下部通常是灰色或綠色或其他某種顏色。換句話說，它已損壞。
是否可以檢查圖像是否已通過這種方式損壞或以其他方式損壞？
如果您正在談論JPEG文件，那麼實用程序 jpeginfo正是您所需要的。它可以檢查文件中不同類型的JPEG錯誤和損壞，並返回錯誤代碼（對腳本最有用的東西），或者只是刪除有錯誤的文件。
我將其用作初始文件的一部分傳輸，以確保所有內容都可以復制，而無需手動檢查。 （在那之後，我確保它們的校驗和不會作為我的常規備份/位保護的一部分而改變。）
該程序是命令行的，並且作為源代碼提供，但是應該很容易可以在任何Linux發行版或具有正確設置的開發環境的Mac上構建和使用。我敢肯定您甚至可以在Windows上使用Cygwin或MinGW做到這一點。 （例如，儘管我不能保證它的完整性，但此博客文章似乎合法，並包含預編譯的下載。）要自己構建它：
$ git將https://github.com/tjko/jpeginfo.git克隆到'jpeginfo'... [...]檢查連接性...完成了$ cd jpeginfo / $ ./configure && make 這應該創建一個 jpeginfo 命令，您可以在本地運行該命令，也可以將其複製到任意位置（可能使用 make install ）。
然後，您可以這樣運行它：
$ ./jpeginfo -c * .jpgtest1.jpg 1996 x 2554 24bit Exif P 6582168 [OK] test2.jpg 1996 x 2554 24bit Exif P 6582116提前結束的JPEG文件[WARNING] test3.jpg損壞的JPEG數據：標記0xe2前1個無關的字節1996 x 2554 24bit Exif P 6582169 [警告] 在這裡，test1.jpg非常好，並且test2.jpg我從末尾刪除了幾個字節，而test3.jpg我更改了標頭中的一些隨機字節。
如果您有RAW文件，請在 DNG驗證上從美國媒體攝影師協會簽出此頁面，或者在數據驗證詳細信息上簽出此頁面，其中涉及使用Adobe的DNG轉換器以批量驗證專有RAW格式。 （不幸的是，這是一個GUI操作，不一定很容易編寫腳本。）
如果您的相機原生輸出DNG的1.2版本，那就更好了，因為它包括內置的MD5校驗和。圖像數據。不幸的是，這似乎沒有與普通的圖像元數據一起存儲-或至少exiftool和exiv2無法識別它，並且它們通常讀取1.2 DNG文件-這意味著據我所知，目前Adobe驗證工具也是唯一利用這一點的方法。
如果這不是要從相機下載圖像，而是要進行計算機到計算機的傳輸，則文件完整性的常見方法是校驗和。
不幸的是，據我所知，常見的“最終用戶”圖像格式（jpeg，png，gif，…）不是單獨進行完整性檢查的。但是據我所知，隱含著自動化處理的問題，將校驗和工具（ CRC32， MD5，...）集成到工作流中可能是一個可行的解決方案。存儲校驗和的一種常見方法是使文件具有相同的文件名，只是具有擴展名，例如： img123.jpg→img123.jpg.md5 。
此這種方法的另一個好處是，您還可以檢查（例如）sidecar文件或您想要以類似機制傳輸的任何其他文件的完整性。而且，即使在將來也保留校驗和文件。 （據我所知，它的缺點是沒有集成到PS，LR或其他常用工具中。）
ImageVerifier完成了您想要的。不幸的是，它不再可供下載，並且支持已於2017年12月31日停止（請參閱 Ingestamatic和ImageVerifier不再出售）。
ImageVerifier（簡稱IV）遍歷尋找圖像文件進行驗證的文件夾層次結構。它可以驗證TIFF，JPEG。 PSD，DNG和非DNG原始數據（例如NEF，CR2）。
IV設計用於處理大量圖像。具有100,000張或更多圖像的文件夾層次結構應該沒有問題。在一次測試中，IV運行了14個小時。
IV進行兩種驗證：結構檢查和哈希檢查。
我開發了 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可以百分百地確定具有以下特徵的文件：標頭/元數據損壞，圖像文件被截斷（strict_level> 0）和設備I / O錯誤。
check-mi通常無法檢測到所有較小的損壞，例如媒體文件的一小部分被不同的值覆蓋。詳細地說，我已經對一個5MB jpeg圖片執行了一個小的隨機實驗，測試了strict_level 1：
用零覆蓋圖像文件的一部分（間隔），您需要間隔大小= 1024KBytes，以便獲得50％的機會發現損壞。用4096字節至1024 KB的間隔大小覆蓋具有不同隨機值的圖像文件的一部分（間隔），可以獲得大約85％的檢測率。 FFmpeg解碼時要嚴格一些，請告訴我。
可接受的答案是使用jpeginfo，這是一個用C編寫的非常老舊且無需維護的工具（並且也不是非常模塊化/可擴展的）。另外，該工具似乎只是在尋找一些特定的EXIF數據點（在源代碼中瀏覽約5分鐘）。
IMO，一種更好的工具，稱為文件類型，非常易於使用–如果您不知道如何編碼，基本上可以將其示例代碼複製粘貼並修改文件名。它會檢查與某些已知文件類型相關的不可思議的數字，並讓您知道要處理的文件類型。
我仍在尋找更多的保護層，而不僅僅是這個。例如，如果任意數據存儲在EXIF元數據之後（或之內）或魔術數字之後，則可能會帶來安全問題。我將繼續研究更多的安全措施，並希望以後再更新此答案。
這是從他們的網頁複製的示例代碼，用於懶惰：
// Node.jsconst 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次下載-因此，這可能是一個很好的指示。