
我正在處理大量地球衛星影像,每張影像都是在同一區域間隔 15 分鐘拍攝的,因此它們彼此非常相似。兩個連續的看起來像這樣:
視訊演算法可以很好地壓縮多個相似影像。然而,這些圖像對於視訊來說太大了(10848x10848),並且使用視訊編碼器會刪除圖像的元數據,因此即使我讓視訊編碼器處理如此大的圖像,提取它們並恢復元數據也會很麻煩。
為了進行一些測試,我將一天的 96 張影像縮小到 1080x1080 像素,總計 40.1MB,並嘗試不同的壓縮,結果如下:
- 壓縮:39.8 MB
- .rar: 39.8 MB
- 7z:39.6 MB
- tar.bz2:39.7 MB
- zpaq v7.14:38.3 MB
- fp8 v2:32.5 MB
- paq8pxd v45:30.9MB
最後三個應該能夠更好地利用上下文,並且確實比傳統壓縮效果更好,但與mp4 視訊相比,壓縮率仍然相當差,mp4 視訊可以將其壓縮到15 MB 甚至更少,同時保持影像質量。
然而,這些壓縮實用程式使用的演算法似乎都沒有像視訊壓縮那樣利用影像的相似性。事實上,使用打包JPG,分別壓縮每個影像,整個集合降至 32.9 MB,非常接近 fp8 和 paq8pxd,但完全沒有利用影像之間的相似性(因為每個影像都是單獨壓縮的)。
在另一個實驗中,我在Matlab中計算了上面兩個圖像的差異,它看起來像這樣:
使用 fp8 壓縮兩張原始影像(總共 219.5 + 217.0 = 436.5 kB),將它們降低到 350.0 kB (80%),但壓縮其中一張和差異影像(作為相同品質的 jpg 並使用 122.5 kB),結果在270.8 kB (62%) 的文件中,因此再次(如mp4 和packJPG 比較所示),fp8 似乎並沒有充分利用這些相似性。即使使用 rar 壓縮,一張影像加上差異在原始影像上的表現也比 fp8 更好。在這種情況下,rar 將其縮小到 333.6 kB (76%)。
我想一定有一個很好的壓縮解決方案來解決這個問題,因為我可以想像很多應用程式。除了我的具體情況之外,我想許多專業攝影師由於連續拍攝或延時影像等而有許多類似的鏡頭。
另外,我不需要無損壓縮,至少對於影像資料不需要(必須保留元資料)。
所以... 是否有一種壓縮方法可以利用被壓縮影像之間的相似性?
答案1
我不知道有哪個特定的軟體可以做到這一點,但有一些關於這個主題的研究。例如,參見文章壓縮相似影像集作者:Samy Ait-Aoudia、Abdelhalim Gabis、Amina Naimi 和使用混合壓縮模型壓縮相似影像集作者:Jiann-Der Lee、Shu-Yen Wan、Chemg-Min Ma、Rui-Feng Wu。
在更實際的層面上,您可以擴展您的減法技術,例如透過編寫一個使用圖像魔術師計算連續影像之間的差異,將結果儲存為 jpeg(如果希望無損,則儲存為壓縮 png)。您將獲得一個基本映像和一組應該小得多的壓縮「增量」映像。使用 ImageMagick 計算差異:
convert image2.png image1.png -compose MinusSrc -composite -depth 24 -define png:compression-filter=2 -define png:compression-level=9 -define png:compression-strategy=1 difference-2-1.png
透過加回來重新計算:
convert image1.png difference-2-1.png -compose Plus -composite image2-reconstructed.png
(您可以使用 jpg 來執行相同的操作,並節省大量空間)。
答案2
希望其他想要壓縮類似圖像/PNG 並透過搜尋找到這裡的人:
我不確定我所研究的用例如何應用於操作照片,因為該連結不再有效。我的用例相似但不相同 - 我希望壓縮非常相似的電腦程式螢幕截圖,因此可能比僅僅壓縮 PNG 檔案更具壓縮性。我透過搜尋找不到解決方案,所以我想出了自己的解決方案,最終得到了瘋狂的 4.4% 壓縮率(而不是透過簡單地壓縮 PNG 得到的 96% 的壓縮率):
我的資料集是 300 個 1920x1080 的 PNG 文件,原始大小為 431.8mb,使用我能找到的 bz2、7z 和類似工具的最佳設定壓縮後大小僅為 417.4mb。我的理解是,原始檔案在 PNG 層級上壓縮得併不理想,因為各種 PNG 最小化工具設法將每個檔案的原始大小從大約 1.4mb 減少到 900kb。
我的想法是,問題在於壓縮工具無法確定資料已經被壓縮,而原始資料中的微小變化可能會導致截然不同的壓縮檔案。因此,我使用設定解壓縮文件ffmpeg
,據我了解,這些設定不會導致任何資料遺失:
for FILE in screenshot-2024*; do ffmpeg -loglevel error -i $FILE -vframes 1 -compression_algo raw -pix_fmt rgb24 $FILE.tiff; done
這將單一檔案大小從 1.4 增加到 6mb,但使用 7z/LZMA2 壓縮導致產生的檔案大小極低,為 19.175.127 位元組,這意味著壓縮量僅為原始大小的 4.4%。
可以透過以下方式將.tiff
文件重新轉換為:.png
for FILE in screenshot-2024*.tiff; do ffmpeg -loglevel error -i $FILE $FILE.png; done
重複的文件結尾當然可以糾正,但這樣在測試時就不會覆蓋您的原始來源。
我們用於壓縮的設定如下:該Solid block size
設定似乎對輸出大小有最大的影響:
- 壓縮等級:9/超高
- 壓縮方式:LZMA2
- 字典大小:512 MB
- 字數:256
- 固體塊大小:512 MB
- 壓縮記憶體使用量:12 GB
由於我們的目標是長期存儲,因此額外的箍和壓縮時間並不是一個大因素,當然,您的里程可能會有所不同。