多くの類似したpng画像のこれらの（ロスレス）圧縮方法が効果的でないのはなぜですか？

私はちょうど次のことを見つけました：png画像の複数の同一のコピーをフォルダに入れてから、次の方法でそのフォルダを圧縮しようとしました：

• tar czf folder.tar.gz folder/
• tar cf folder.tar folder/ && xz --stdout folder.tar > folder.tar.xz （これは同一の画像ではうまく機能しますが、類似の画像ではゲインはゼロです）
• zip -r folder.zip folder/

私はの大きさをチェックすると.tar.gz、.tar.xz、.zip私はそれはほとんどのものと同じであることに気づきましたfolder/。
png画像自体は高レベルの圧縮を行う可能性があるため、それ以上圧縮できないことを理解しています。ただし、多くの類似（この場合は同一）のpng画像をアーカイブにマージしてからアーカイブを圧縮すると、必要なサイズが著しく減少することが予想されます。同一の画像の場合、私はほぼ単一の画像のサイズのサイズを期待します。

圧縮アルゴリズムの仕組みをご覧ください。少なくとも、Lempel-Zivファミリーのもの（gzip LZ77を使用し、zipどうやらほとんどのほか行い、およびxz LZMAを使用しています）圧縮ややローカル：遠く離れたお互い缶から嘘を識別できないことの類似点。

詳細は方法によって異なりますが、一番下の行は、アルゴリズムが2番目の画像に到達するまでに、最初の画像の開始を既に「忘れてしまった」ことです。等々。

圧縮方法のパラメーターを手動で変更してみてください。ウィンドウサイズ（LZ77）または ブロック/チャンクサイズ（後の方法）は少なくとも2つのイメージと同じ大きさで、おそらくさらに圧縮されます。

上記は、同一の画像またはほぼ同じ画像がある場合にのみ実際に適用されることに注意してください同一の非圧縮画像。違いがある場合、圧縮された画像はメモリ内で同じように見えないことがあります。PNG圧縮の仕組みがわかりません。共有部分文字列の画像の16進表現を手動で確認することをお勧めします。

また、パラメーターと冗長性を変更して活用しても、1つのイメージのサイズに達することはありません。辞書が大きくなると、コードワードサイズが大きくなり、2つの画像がまったく同じであっても、複数のコードワード（最初の画像を指す）を使用して2つ目の画像をエンコードする必要があります。

これが起こる理由。ここでは実際に2つの異なる効果が発生します。

• 各ファイルは個別に圧縮されます。 zipなどの一部のアーカイブプログラムは、各ファイルを個別に圧縮します。1つのファイルから別のファイルにメモリはありません。つまり、各ファイルは個別に圧縮され、圧縮されたファイルはアーカイブに連結されます。

• 短期記憶。 一部のアーカイブプログラムでは、1つのファイルに関する情報を使用して、次のファイルをより適切に圧縮できます。ファイルを効果的に連結し、結果を圧縮します。これは改善です。

  この詳細については、Nayukiの回答も参照してください。

  ただし、2つ目の問題があります。zip、gzip、bzip2などの一部の圧縮スキームには、メモリが制限されています。データをオンザフライで圧縮し、過去32 KBのデータを記憶しますが、ファイル内で以前に発生したデータについては何も記憶しません。つまり、重複が32KBを超えて発生した場合、重複したデータを見つけることができません。その結果、同一のファイルが短い（約32KBより短い）場合、圧縮アルゴリズムは複製されたデータを削除できますが、同一のファイルが長い場合、圧縮アルゴリズムは無駄になり、価値がなくなります。データの重複。（Bzipは、32KBではなく、過去900KB程度のデータを記憶します。）

  すべての標準圧縮アルゴリズムには、彼らはパターンを検出することができないそれを超える最大メモリサイズを、...しかし、いくつかのために、この数は他よりもはるかに大きいです。Bzipの場合、900KBのようなものです。xzの場合、8MBのようなものです（デフォルト設定）。7zの場合、2GBのようなものです。2GBは、PNGファイルの複製コピー（通常は2GBよりもはるかに小さい）を認識するのに十分な大きさです。さらに、7zは、コンプレッサーの動作を改善するために、アーカイブ内で互いに類似している可能性のあるファイルを隣に配置することについても賢くしようとします。tarはそれについて何も知りません。

  この効果の詳細については、Raphaelの答えとNayukiの答えも参照してください。

これが設定にどのように適用されるか。 特定の例では、PNG画像を使用しています。PNG画像自体は圧縮されているため、各PNGファイルは、基本的にランダムに見えるバイトのシーケンスであり、ファイル内にパターンや重複がないと考えることができます。単一のPNG画像を見る場合、コンプレッサーが活用するものは何もありません。したがって、1つのPNGファイルを圧縮しようとすると（または、1つのPNGファイルのみを含むzip / tar / ...アーカイブを作成すると）、圧縮は行われません。

次に、同じPNGファイルの複数のコピーを保存しようとするとどうなるかを見てみましょう。

• 小さなファイル。PNGファイルが非常に小さい場合、zip以外のすべてがうまく機能します。Zipは見事に失敗します。各ファイルを個別に圧縮するため、ファイル間の冗長性/重複を検出する機会はありません。さらに、各PNGファイルを圧縮しようとするため、圧縮は行われません。zipアーカイブのサイズは非常に大きくなります。対照的に、tarアーカイブ（gzip、bzip2、またはxzで圧縮されているかどうか）と7zアーカイブのサイズは小さくなります。これは、基本的にファイルのコピーを1つ保存し、他のコピーはすべて同じであることに気付くためです-それらは恩恵を受けますあるファイルから別のファイルにメモリを保持することから。

• 大きなファイル。PNGファイルが大きい場合、7zのみが適切に機能します。特に、zipは引き続き失敗し続けます。また、tar.zipおよびtar.bzip2は、ファイルのサイズが圧縮機のメモリウィンドウよりも大きいため、ひどく失敗します。圧縮機はファイルの最初のコピーを見るため、圧縮できません（既に圧縮されているため） ）; ファイルの2番目のコピーの開始点を見るまでに、最初のファイルの開始点にあるバイトシーケンスをすでに忘れており、このデータが実際に重複しているという接続を確立できません。

  対照的に、tar.xzと7zは、大きなPNGファイルの複数のコピーで引き続き優れた機能を発揮します。「小さなメモリサイズ」の制限はなく、ファイルの2番目のコピーが最初のコピーと同一であることに気付くことができるため、2回目に保存する必要はありません。

これについてできること。7zを使用します。同一または類似のファイルを検出し、その場合に非常にうまく圧縮するのに役立つ一連のヒューリスティックがあります。lzop圧縮を使用してlrzipを調べることもできます。

どうやって知るの？ これを確認するには、ランダムバイトを含むファイルのコピーを100個使用していくつかの実験を試みました。4KBファイルを100コピー、1MBファイルを100コピー、16MBファイルを100コピー試しました。私が見つけたものは次のとおりです。

Size of file      Size of compressed archive (with 100 copies)
                  zip  tar.gz  tar.bz2  tar.xz    7z
         4KB    414KB     8KB     10KB     5KB    5KB
         1MB    101MB   101MB    101MB     1MB    2MB
        16MB    1.6G    1.6GB    1.6GB   1.6GB  401MB

ご覧のとおり、zipはファイルがどれほど小さくても恐ろしいものです。画像が大きすぎない場合は7zとxzの両方が適しています（ただし、重複しているものと重複していないものが混在している場合、xzは壊れやすく、画像がアーカイブに配置される順序に依存します）。7zは、大きなファイルであっても非常に優れています。

参照。 これは、Super Userでの多くの投稿でも説明されています。見てみましょう：

• Gzip圧縮で重複したデータの塊が削除されないのはなぜですか？
• Zipが単一のファイルを同じコンテンツの複数のファイルよりも小さく圧縮できるのはなぜですか？
• 多くの同様の大きなファイルを圧縮する
• 類似ファイルを効率的に圧縮する
• 重複排除も行うWindows用の圧縮プログラムまたはアーカイバプログラムはありますか？
• 多くの同一ファイルのより効率的なファイル圧縮プログラム？

まず、PNG画像形式は基本的にDEFLATE圧縮形式を介してプッシュされる生のRGBピクセル（ライトフィルタリングを含む）であることに注意してください。一般的に、圧縮ファイル（PNG、JPEG、MP3など）を再度圧縮してもメリットはありません。そのため、実際の目的のために、PNGファイルを残りの実験では非圧縮のランダムデータとして扱うことができます。

次に、ZIPおよびgzip形式もDEFLATEコーデックを使用することに注意してください。（これにより、1つのファイルを圧縮するのとgzip圧縮するのとで出力サイズが本質的に同じになる理由が説明されます。）

次に、各テストケースについて個別にコメントできるようにします。

• tar czf folder.tar.gz folder/

  これにより、すべての同一のPNGファイルを連結する（圧縮されていない）TARファイルが作成されます（わずかなメタデータとパディングが追加されます）。次に、この単一ファイルがgzipコンプレッサーを介して送信され、1つの圧縮出力ファイルが作成されます。

  残念ながら、DEFLATE形式は32768バイトのLZ77辞書ウィンドウのみをサポートしています。そのため、TARに反復データが含まれている場合でも、PNGファイルが32 KiBを超える場合、DEFLATEコンプレッサーは、同一データが繰り返し使用されるという事実を十分に活用することができます。

  一方、たとえば20 KBのPNGファイルを10回複製してこの実験を再試行すると、20 KBよりもわずかに大きいgzipファイルを取得する可能性が非常に高くなります。

• tar cf folder.tar folder/ && xz --stdout folder.tar > folder.tar.xz

  これにより、以前と同様にTARファイルが作成され、xz形式とLZMA / LZMA2コンプレッサーが使用されます。この状況ではLZMAに関する情報を見つけることができませんでしたが、7-Zip for Windowsからは、大きな辞書ウィンドウサイズ（64 MiBなど）をサポートできることがわかっています。そのため、最適ではない設定を使用していた可能性があり、LZMAコーデックがTARファイルを1つのPNGファイルのサイズに縮小できた可能性があります。

• zip -r folder.zip folder/

  ZIP形式は「ソリッド」アーカイブをサポートしていません。つまり、すべてのファイルが個別に圧縮されます。すべてのファイルは非圧縮であると想定しました。したがって、すべてのファイルが同一であるという事実を悪用することはできず、ZIPファイルはすべてのファイルを直接連結したものと同じ大きさになります。

問題は、（ほとんどの）圧縮スキームには、持っているデータに関する知識が欠けているということです。PNGをビットマップに解凍し、tarballで圧縮しても、（かなり）小さい結果は得られません。

多くの同様の画像の場合、適切な圧縮スキームはビデオコーデックです。

ロスレスコーディングを使用すると、期待するほぼ完璧な圧縮結果を達成する必要があります。

テストする場合は、次のようなものを使用します。

ffmpeg -i img%03d.png -c:v libx264 -c:v libx264 -profile:v high444 -crf 0 out.mp4

https://trac.ffmpeg.org/wiki/Create%20a%20video%20slideshow%20from%20images

PNGは、Filters + LZ77 + Huffmanの組み合わせです（LZ77 + Huffmanの組み合わせはDeflateと呼ばれます）：

ステップ1）フィルターがNoneと異なる場合、ピクセルの値は隣接するピクセルとの差に置き換えられます（詳細については、http：//www.libpng.org/pub/png/book/chapter09.htmlを参照してください） 。これにより、グラデーションを使用した画像の圧縮が増加し（... 4 5 6 7が... 1 1 1 1 1になります）、同じ色の領域で役立ちます（... 3 3 3 5 5 5 5 5が0になります） 0 0 2 0 0 0 0 0）。デフォルトでは、フィルターは24ビット画像で有効になり、パレット付きの8ビット画像で無効になります。

ステップ2）データはLZ77で圧縮され、繰り返される（一致する）バイト文字列を、一致までの距離と一致の長さを含むタプルに置き換えます。

ステップ3）ステップ2の結果は、固定長シンボルを可変長コードに置き換えるハフマンコードでエンコードされます。シンボルが頻繁になるほど、コードは短くなります。

複数の問題があります：

わずかなピクセルに影響する小さな変更により、PNG圧縮の3つのステップの結果が変更されます。

1）使用されるフィルターに応じて、隣接するピクセルのフィルター処理された値が変わります。それは小さな変化の影響を増幅します。

2）変更は、そのエリアへの一致が異なることを意味します。たとえば、333333を333533に変更すると、333333の別のオカレンスが一致しなくなるため、異なる距離で333333に別の一致が選択されるか、同じ一致を選択しますが、長さが短く、最後の3バイトに別の一致が選択されます。それだけで結果が大きく変わります。

3）最大の問題はステップ3にあります。ハフマンコードは可変ビット数を使用するため、小さな変更でも後続のすべてが整列しなくなります。知っている限り、ほとんどの圧縮アルゴリズムは、バイトアラインされていない一致を検出できないため、コンプレッサーがバイトアラインされていない一致を検出できない限り、変更後に既に圧縮されているデータの圧縮を防止します（または少なくとも大幅に削減します）。

その他の問題は、すでに他の返信でカバーされています。

4）Gzipは同じDeflateアルゴリズムと32KBディクショナリを使用するため、PNGファイルが32KBより大きい場合、同一であっても一致は検出されません。Bzip2は900 KBブロックを使用するため、この点で優れています。XZはLZMAを使用します。IIZには、デフォルトの圧縮レベルで4 MBの辞書があります。5）Zip形式は固体圧縮を使用しないため、類似または同一のファイルを圧縮することはできません。

おそらく、PAQまたはPPMDファミリーのコンプレッサーの方が圧縮率は高くなりますが、同様の画像ファイルを大量に圧縮する必要がある場合は、次の3つのアプローチを検討できます。

1）圧縮されていない画像を保存し（PNG -0または圧縮なしの形式で）、大きな辞書またはブロックサイズのコンプレッサーで圧縮します。（LZMAはうまく機能します）

2）別のオプションは、フィルターを保持するが、PNGからDeflate圧縮を削除することです。これは、たとえば（AdvDef）ユーティリティを使用して実行できます。次に、結果の非圧縮PNGを圧縮します。解凍後、非圧縮PNGを保持するか、AdvDefで再度圧縮できます（ただし、時間がかかります）。

どちらが最も圧縮されるかを確認するには、両方のアプローチをテストする必要があります。

3）最後のオプションは、ビデオのPNG画像を変換し、x264ロスレスのようなロスレスビデオコンプレッサーで圧縮し（適切なカラーフォーマットを使用するように特別に注意して）、抽出時にフレームを個々のPNG画像に抽出します。それはffmpegでできます。また、フレーム番号と元の名前の間のマッピングを保持する必要があります。

これは最も複雑なアプローチですが、PNGがすべてアニメーションの一部である場合、最も効果的です。ただし、必要に応じて透明度をサポートするビデオ形式が必要になります。

編集：MNG形式もあり、あまり使用されません。

特別なデータセットがある場合、多目的ツールではなく特別なアルゴリズムを使用します。

答えは、あなたが選んだ可逆圧縮はあなたがすることに対して作られていないということです。同じ画像を2回圧縮することを期待する人はいません。たとえそれを（誤って）行ったとしても、以前のすべての入力に対してチェックすると、アルゴリズムがO（n ^ 2）になります（もう少し良いかもしれませんが、少なくともnaivアプローチはn ^ 2）。

O（n）での実行時にテストした圧縮プログラムのほとんどは、最適な圧縮率よりも速度を重視しています。特に最近では、数MBを節約するためだけにコンピューターを5時間実行したい人はいません。入力が大きい場合、O（n）を超えるものはランタイムの問題になります。

別の問題はラムです。入力が十分に大きくなった時点で、入力のすべての部分にアクセスすることはできません。これを無視しても、ほとんどの人は何かを圧縮するためだけにRAMやCPU全体を放棄したくありません。

圧縮したいファイルにパターンがある場合、それらに対して手動操作を行うか、独自の圧縮を記述するか、「アーカイブ」タイプの圧縮（ナノ）を使用する必要があります。長期保存用の圧縮。日常使用するには遅すぎます。

別のオプションは、可逆ビデオ圧縮です。

PNGファイル形式は、既に内部的にDEFLATE圧縮アルゴリズムを使用しています。これは、xz、gzip、およびzipで使用されるものと同じアルゴリズムです-いくつかのバリエーションがあります。tar.gzそして、tar.xzファイル間の類似性を活用しますが、そうしzipません。

したがって、実際には、DEFLATE圧縮ファイルに対してDEFLATE圧縮を実行します。これが、ファイルがほぼ元のサイズを保持する理由です。

bzip2それは（ほぼ）同一のファイルに来るとき、プログラム（また、関連するアルゴリズム）が優れています。

# for i in $(seq 4); do cp test.png test$i.png; done
# tar -cjf archive.tar.bz2 *.png
# ls -l
-rw-r--r-- 1 abcde users  43813 15. Jul 08:45 test.png
-rw-r--r-- 1 abcde users  43813 15. Jul 08:45 test1.png
-rw-r--r-- 1 abcde users  43813 15. Jul 08:46 test2.png
-rw-r--r-- 1 abcde users  43813 15. Jul 08:46 test3.png
-rw-r--r-- 1 abcde users  43813 15. Jul 08:46 test4.png
-rw-r--r-- 1 abcde users  68115 15. Jul 08:47 archive.tar.bz2