
私が扱っているのは地球の衛星画像の大規模なアーカイブです。各画像は 15 分間隔で同じ地域を撮影したものなので、非常によく似ています。2 つの連続した画像は、次のようになります。
ビデオ アルゴリズムは、複数の類似した画像を非常にうまく圧縮します。ただし、この画像はビデオ (10848 x 10848) には大きすぎ、ビデオ エンコーダーを使用すると画像のメタデータが削除されるため、このような大きな画像で動作するビデオ エンコーダーを入手できたとしても、メタデータを抽出して復元するのは面倒です。
テストを行うために、ある日の 96 枚の画像を 1080 x 1080 ピクセル (合計 40.1 MB) に縮小し、さまざまな圧縮を試してみたところ、次の結果が得られました。
- zip: 39.8 MB
- rar: 39.8 MB
- 7z:39.6MB
- tar.bz2: 39.7 MB
- zpaq v7.14: 38.3 MB
- fp8 v2: 32.5 MB
- paq8pxdv45: いいえ30.9MB
最後の 3 つは、コンテキストをより有効に活用し、従来の圧縮よりも実際に効果的であると考えられていますが、画質を維持したまま 15 MB 以下に圧縮できる mp4 ビデオと比較すると、圧縮率は依然としてかなり低いです。
しかし、これらの圧縮ユーティリティで使用されるアルゴリズムはどれも、ビデオ圧縮のように画像の類似性を活用していないようです。実際、パックJPG各画像を個別に圧縮する では、セット全体のサイズは 32.9 MB まで小さくなり、fp8 や paq8pxd にかなり近くなりますが、画像間の類似性はまったく活用されません (各画像が個別に圧縮されるため)。
別の実験では、上記の 2 つの画像の差を Matlab で計算したところ、次のようになりました。
両方の元の画像 (合計 219.5 + 217.0 = 436.5 kB) を fp8 で圧縮すると、350.0 kB (80%) まで小さくなりますが、そのうちの 1 つと差分画像を圧縮すると (同じ品質の jpg として 122.5 kB を使用)、ファイルは 270.8 kB (62%) になります。したがって、(mp4 と packJPG の比較で明らかになったように)、fp8 は類似点をあまり活用していないようです。rar で圧縮した場合でも、1 つの画像と差分は元の画像に対して fp8 よりも優れています。その場合、rar は 333.6 kB (76%) まで小さくなります。
この問題には、多くの用途が考えられるので、適切な圧縮ソリューションがあるはずです。私のケース以外にも、多くのプロの写真家は、連続撮影やタイムラプス画像などにより、類似したショットを多数持っていると思います。このような圧縮の恩恵を受けるケースはすべてそうです。
また、少なくとも画像データについては、ロスレス圧縮は必要ありません (メタデータは保持する必要があります)。
それで... 圧縮された画像間の類似性を活用する圧縮方法はありますか?
答え1
これを行う特定のソフトウェアは知りませんが、このテーマに関する研究はいくつかあります。たとえば、以下の記事をご覧ください。類似画像セットの圧縮サミー・アイト・アウディア、アブデルハリム・ガビス、アミナ・ナイミ、ハイブリッド圧縮モデルを使用して類似画像セットを圧縮する著者:Jiann-Der Lee、Shu-Yen Wan、Chemg-Min Ma、Rui-Feng Wu。
より実用的なレベルでは、減算のテクニックを拡張することができます。たとえば、次のようなスクリプトを書くことができます。イメージマジック連続する画像間の差を計算し、結果を jpeg (ロスレスにしたい場合は圧縮された png) として保存します。1 つの基本画像と、それよりはるかに小さい圧縮された「デルタ」画像のセットが得られます。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 ファイルを単に zip で圧縮するよりもはるかに圧縮しやすい可能性があります。検索しても解決策が見つからなかったので、独自の方法を思いつき、最終的に 4.4% という驚異的な圧縮率を達成しました (PNG を単純に圧縮する単純な使用では 96% でした)。
私のデータセットは、1920x1080 の PNG ファイル 300 個で、生のサイズは 431.8 MB でしたが、bz2、7z などのツールで見つけることができた最適な設定で、わずか 417.4 MB に圧縮されました。私の理解では、さまざまな PNG 縮小ツールによって生のサイズがファイルあたり約 1.4 MB から 900 KB に削減されたため、ソース ファイルは PNG レベルでは理想的に圧縮されていなかったようです。
私の考えでは、問題は圧縮ツールがデータがすでに圧縮されていることを認識できず、生のデータの小さな変更によって圧縮ファイルが大きく異なる可能性があるということでした。そこで、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 MB から 6 MB に増加しましたが、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
私たちの目標は長期保管だったので、追加のフープや圧縮時間は大きな要素ではありませんでしたが、もちろん、結果は異なる可能性があります。