Birçok benzer PNG görüntüsünün bu (kayıpsız) sıkıştırma yöntemleri neden etkisiz?

Az önce şu şeyle karşılaştım: Bir png görüntüsünün birden çok özdeş kopyasını bir klasöre koydum ve sonra bu klasörü aşağıdaki yöntemlerle sıkıştırmaya çalıştım:

• tar czf folder.tar.gz folder/
• tar cf folder.tar folder/ && xz --stdout folder.tar > folder.tar.xz (bu özdeş görüntüler için iyi çalışır, ancak benzer görüntüler için kazanç sıfırdır)
• zip -r folder.zip folder/

Ben boyutunu işaretlendiğinde .tar.gz, .tar.xz, .zipben neredeyse biriyle aynı olduğunu fark etti folder/.
Bir png görüntüsünün kendisinin yüksek bir sıkıştırma seviyesine sahip olabileceğini ve bu nedenle daha fazla sıkıştırılamayacağını anlıyorum. Bununla birlikte, bir çok benzer (bu durumda aynı) png görüntülerini bir arşive birleştirip arşivi sıkıştırırken, gerekli boyutun belirgin şekilde azalmasını beklerim. Özdeş görüntüler söz konusu olduğunda, kabaca tek bir görüntünün boyutundan bir boyut bekleyebilirim.

Sıkıştırma algoritmalarının nasıl çalıştığına bir göz atın. En azından Lempel-Ziv ailesindekiler ( gzip LZ77 kullanır , zipgörünüşte çoğunlukla da yapar ve xz LZMA kullanır ) biraz yerel olarak sıkıştırır : Birbirinden uzakta yatan benzerlikler tanımlanamaz.

Ayrıntılar yöntemler arasında farklılık gösterir, ancak sonuçta algoritma ikinci görüntüye ulaştığında, birincinin başlangıcını "unutmuş" dur. Ve bunun gibi.

Sıkıştırma yönteminin parametrelerini manuel olarak değiştirmeyi deneyebilirsiniz; pencere boyutu (LZ77) ise resp. blok / yığın boyutu (sonraki yöntemler) en az iki görüntü kadar büyük, muhtemelen daha fazla sıkıştırma göreceksiniz.

Yukarıdakilerin yalnızca özdeş görüntüleriniz veya neredeyse aynı sıkıştırılmamış görüntüleriniz varsa geçerli olduğunu unutmayın . Farklılıklar varsa, sıkıştırılmış görüntüler bellekte benzer görünmeyebilir. PNG sıkıştırmasının nasıl çalıştığını bilmiyorum; paylaşılan alt dizeler için sahip olduğunuz görüntülerin onaltılık temsillerini manuel olarak kontrol etmek isteyebilirsiniz.

Ayrıca, değiştirilen parametreler ve yararlanma yedekli olsa bile, bir görüntünün boyutuna inmeyeceğinizi unutmayın. Daha büyük sözlükler daha büyük kod-kelime boyutu anlamına gelir ve iki görüntü tam olarak aynı olsa bile, ikincisini birden çok kod-kelime (birinciyi işaret eden) kullanarak kodlamanız gerekebilir.

Bu neden oluyor. Aslında burada iki farklı efekt oluyor:

• Her dosya bağımsız olarak sıkıştırılır. Zip dahil olmak üzere bazı arşiv programları, her dosyayı bir dosyadan diğerine bellek olmadan bağımsız olarak sıkıştırır. Başka bir deyişle, her dosya ayrı olarak sıkıştırılır, daha sonra sıkıştırılmış dosyalar bir arşive birleştirilir.

• Kısa süreli hafıza. Bazı arşiv programları, bir sonraki dosyayı daha iyi sıkıştırmak için bir dosya hakkındaki bilgileri kullanabilir. Dosyaları etkili bir şekilde birleştirir, ardından sonucu sıkıştırırlar. Bu bir gelişme.

  Bununla ilgili daha fazla tartışma için ayrıca Nayuki'nin cevabına bakınız .

  Ancak ikinci bir sorun daha var. Zip, gzip ve bzip2 dahil olmak üzere bazı sıkıştırma şemalarının sınırlı bir belleği vardır. Verileri anında sıkıştırırlar ve geçmiş 32KB'lik verileri hatırlarlar, ancak dosyada daha önce meydana gelen veriler hakkında hiçbir şey hatırlamazlar. Başka bir deyişle, kopyalar 32KB'den daha uzaktaysa çoğaltılan verileri bulamazlar. Sonuç olarak, özdeş dosyalar kısaysa (yaklaşık 32 KB'den kısa), sıkıştırma algoritması çoğaltılan verileri kaldırabilir, ancak özdeş dosyalar uzunsa, sıkıştırma algoritması hosed olur ve değersiz hale gelir: verilerinizde kopya. (Bzip, 32KB yerine geçmiş 900KB veya daha fazla veriyi hatırlar.)

  Tüm standart sıkıştırma algoritmaları var bazı onlar kalıplarını tespit başarısız olan ötesinde maksimum bellek boyutu, ... ama bazıları için bu sayı diğerlerine göre çok daha büyüktür. Bzip için, 900KB gibi bir şey. Xz için, 8MB gibi bir şeydir (varsayılan ayarlarla). 7z için bu 2GB gibi bir şey. 2 GB, PNG dosyalarının çoğaltılmış kopyalarını (genellikle 2 GB'den çok daha küçük) tanıyacak kadar büyüktür. Buna ek olarak, 7z, kompresörün daha iyi çalışmasına yardımcı olmak için, birbirine benzemesi muhtemel dosyaları arşivde yan yana yerleştirme konusunda da akıllı davranmaya çalışır; tar bunun hakkında hiçbir şey bilmiyor.

  Bu etkinin daha fazla açıklaması için ayrıca Raphael'in cevabına ve Nayuki'nin cevabına bakınız .

Bunun ayarınız için nasıl geçerli olduğu. Özel örneğiniz için PNG görüntüleri ile çalışıyorsunuz. PNG görüntülerinin kendileri sıkıştırılır, bu nedenle her PNG dosyasını temel olarak rasgele görünümlü bayt dizisi olarak düşünebilirsiniz, dosya içinde desen veya çoğaltma olmadan. Tek bir PNG görüntüsüne bakarsa, bir kompresörün yararlanabileceği hiçbir şey yoktur. Böylece, tek bir PNG dosyasını sıkıştırmaya çalışırsanız (veya yalnızca tek bir PNG dosyası içeren bir zip / tar / ... arşivi oluşturursanız), herhangi bir sıkıştırma elde edemezsiniz.

Şimdi, aynı PNG dosyasının birden fazla kopyasını saklamaya çalışırsanız ne olduğuna bakalım:

• Küçük dosyalar. PNG dosyası çok küçükse, zip hariç her şey harika çalışır. Zip muhteşem bir şekilde başarısız olur: her dosyayı bağımsız olarak sıkıştırır, bu nedenle dosyalar arasındaki yedekliliği / çoğaltmayı algılama şansı yoktur. Dahası, her PNG dosyasını sıkıştırmaya çalıştıkça hiçbir sıkıştırma elde etmez; zip arşivinin boyutu çok büyük olacaktır. Buna karşılık, katran arşivinin boyutu (gzip, bzip2 veya xz ile sıkıştırılmış olsun) ve 7z arşivi, temelde dosyanın bir kopyasını sakladığı ve diğerlerinin aynı olduğunu fark ettiği için küçük olacaktır. bir dosyadan diğerine belleği tutmaktan.

• Büyük dosyalar. PNG dosyası büyükse, sadece 7z iyi çalışır. Özellikle, zip muhteşem bir şekilde başarısız olmaya devam ediyor. Ayrıca, tar.zip ve tar.bzip2, dosyanın boyutu kompresörün bellek penceresinden daha büyük olduğu için kötü bir şekilde başarısız oluyor: kompresör dosyanın ilk kopyasını gördüğünden, küçülemiyor (zaten sıkıştırılmış olduğundan) ); dosyanın ikinci kopyasının başlangıcını görmeye başladığında, ilk dosyanın başlangıcında görülen bayt dizilerini zaten unutmuş ve bu verinin gerçekte bir kopya olduğu bağlantısını yapamamıştır.

  Buna karşılık, tar.xz ve 7z büyük bir PNG dosyasının birden çok kopyasıyla harika sonuçlar almaya devam ediyor. "Küçük bellek boyutu" sınırlamasına sahip değiller ve dosyanın ikinci kopyasının ilk kopyayla aynı olduğunu fark edebiliyorlar, bu yüzden ikinci kez saklamaya gerek yok.

Bu konuda ne yapabilirsiniz? 7z kullanın. Aynı veya benzer dosyaları algılamaya ve bu durumda gerçekten iyi sıkıştırmaya yardımcı olacak bir grup buluşsal yöntem vardır. Ayrıca lrzip'e lzop sıkıştırması ile de bakabilirsiniz.

Nasıl bilebilirim? Rasgele bayt içeren bir dosyanın 100 kopyasıyla yapılan bazı denemeleri deneyerek bunu doğrulayabildim. Bir 4KB dosyasının 100 kopyasını, 1MB dosyasının 100 kopyasını ve 16MB dosyasının 100 kopyasını denedim. İşte bulduğum:

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

Gördüğünüz gibi zip, dosyanız ne kadar küçük olursa olsun korkunç. 7z ve xz, resimleriniz çok büyük değilse iyi olur (ancak xz, kırılgan ve bazı kopyalarınız ve bazı kopya olmayanlar birlikte karıştırılırsa, görüntülerin arşive yerleştirilme sırasına bağlı olacaktır). 7z, büyük dosyalar için bile oldukça iyi.

Referanslar. Bu aynı zamanda Süper Kullanıcı üzerinden bir sürü gönderide de açıklanmaktadır. Bir göz at:

• Gzip sıkıştırması yinelenen veri yığınlarını neden ortadan kaldırmıyor?
• Zip neden aynı içeriğe sahip birden fazla dosyadan daha küçük tek dosyaları sıkıştırabilir?
• Benzer büyük dosyaları sıkıştırmak
• Benzer Dosyaları Verimli Bir Şekilde Sıkıştır
• Windows için tekilleştirme de yapan bir sıkıştırma veya arşivleyici programı var mı?
• Birçok özdeş dosya için daha verimli dosya sıkıştırma programı?

İlk olarak, PNG görüntü formatının temelde DEFLATE sıkıştırma formatı boyunca itilmiş ham RGB pikseller (bazı ışık filtrelemeli) olduğuna dikkat edin. Genel olarak, sıkıştırılmış dosyalar (PNG, JPEG, MP3, vb.) Tekrar sıkıştırılmanın bir yararı olmayacaktır. Dolayısıyla, pratik amaçlar için PNG dosyanızı denemenin geri kalanı için sıkıştırılamaz rastgele veriler olarak ele alabiliriz.

İkinci olarak, ZIP ve gzip biçimlerinin DEFLATE kodekini kullandığını unutmayın. (Bu, tek bir dosyayı sıkıştırmak yerine sıkıştırmanın neden aynı çıktı boyutunu üreteceğini açıklar.)

Şimdi her test senaryosu için ayrı ayrı yorum yapmama izin verin:

• tar czf folder.tar.gz folder/

  Bu, tüm özdeş PNG dosyalarınızı birleştiren (sıkıştırılmamış) bir TAR dosyası oluşturur (az miktarda meta veri ve dolgu eklenir). Daha sonra bu tek dosya, sıkıştırılmış bir çıktı dosyası oluşturmak için gzip kompresöründen gönderilir.

  Ne yazık ki, DEFLATE biçimi yalnızca 32768 baytlık bir LZ77 sözlük penceresini destekler. TAR yinelenen veriler içeriyor olsa da, PNG dosyanız 32 KiB'den büyükse, kesin olarak DEFLATE kompresör, aynı verilerin tekrarlanan olmasından yararlanmak için verileri yeterince geri hatırlayamaz.

  Öte yandan, bu deneyimi 10 kez çoğaltılmış 20 KB PNG dosyasıyla yeniden denerseniz, muhtemelen 20 KB'den biraz daha büyük bir gzip dosyası elde edersiniz.

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

  Bu, daha önce olduğu gibi bir TAR dosyası oluşturur ve ardından xz biçimini ve LZMA / LZMA2 kompresörünü kullanır. Bu durumda LZMA hakkında bilgi bulamadım, ancak Windows için 7-Zip'den büyük sözlük penceresi boyutlarını (örneğin 64 MiB) destekleyebileceğini biliyorum. Bu nedenle, en düşük ayarları kullanmanız ve LZMA kodekinin TAR dosyasını yalnızca bir PNG dosyasının boyutuna küçültmüş olması mümkündür.

• zip -r folder.zip folder/

  ZIP biçimi "katı" arşivleri desteklemez; yani her dosya bağımsız olarak sıkıştırılır. Her dosyanın sıkıştırılamaz olduğunu varsaydık. Bu nedenle, her dosyanın özdeş olması istismar edilemez ve ZIP dosyası, tüm dosyaların doğrudan birleştirilmesi kadar büyük olacaktır.

Sorun şu ki, (çoğu) sıkıştırma şeması sahip olduğunuz veriler hakkında bilgi sahibi değildir. PNG'lerinizi bitmap'lere sıkıştırıp tarball'da sıkıştırsanız bile (önemli ölçüde) daha küçük sonuçlar elde edemezsiniz.

Birçok benzer görüntü olması durumunda, uygun bir sıkıştırma şeması bir video kodeki olacaktır.

Kayıpsız kodlama kullanarak neredeyse beklediğiniz mükemmel sıkıştırma sonucunu elde etmelisiniz.

Test etmek istiyorsanız, böyle bir şey kullanın:

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, Filtreler + LZ77 + Huffman (LZ77 + Huffman kombinasyonuna Deflate denir) kombinasyonudur:

1. adım) filtre Yok'tan farklıysa, piksellerin değeri bitişik piksellerden farklılıkla değiştirilir (daha fazla ayrıntı için bkz. http://www.libpng.org/pub/png/book/chapter09.html ) . Bu, görüntülerin degradelerle sıkıştırılmasını artırır (böylece ... 4 5 6 7 olur ... 1 1 1 1) ve aynı renkteki alanlarda yardımcı olabilir (... 3 3 3 5 5 5 5 5 0 olur 0 0 2 0 0 0 0 0). Varsayılan olarak filtreler 24 bitlik görüntülerde etkinleştirilir ve paletle 8 bitlik görüntülerde devre dışı bırakılır.

adim 2) veriler, tekrarlanan (eşleşme) bayt dizelerini, eşleşmeye olan mesafeyi ve eşleşmenin uzunluğunu içeren bir tuple ile değiştiren LZ77 ile sıkıştırılır.

Aşama 3) Aşama 2'nin sonucu, sabit uzunluklu sembolleri değişken uzunluklu kodlarla değiştiren Huffman kodu ile kodlanır, sembol ne kadar sık ​​olursa kod o kadar kısa olur.

Birden fazla sorun var:

Birkaç pikseli etkileyen küçük bir değişiklik, png sıkıştırmasının 3 adımındaki sonuçlarda değişikliklere neden olur:

1) Bitişik piksellerin filtrelenmiş değeri değişecektir (kullanılan filtreye bağlı olarak). Bu, küçük değişikliklerin etkilerini artıracaktır.

2) Değişiklik, o bölgeyle eşleşmenin farklı olacağı anlamına gelecektir. Örneğin, 333333'ü 333533 olarak değiştirmek, 333333'ün başka bir oluşumunun artık eşleşmemesine neden olur, bu nedenle farklı bir mesafeyle 333333'e başka bir eşleşme seçer veya aynı eşleşmeyi seçer, ancak daha kısa bir uzunluk ve daha sonra son 3 bayt için başka bir eşleşme seçer. Kendi başına sonuçları çok değiştirecek.

3) En büyük sorun 3. adımdadır. Huffman kodu değişken sayıda bit kullanır, böylece küçük bir değişiklik bile takip eden her şeyin artık hizalanmamasına neden olur. AFAIK Çoğu sıkıştırma algoritması, bayt hizalı olmayan eşleşmeleri algılayamaz, böylece kompresör bayt hizalı olmayan eşleşmeleri algılayamazsa, değişikliği izleyen zaten sıkıştırılmış veriler üzerinde sıkıştırmayı önler (veya en azından çok azaltır).

Diğer konular zaten diğer yanıtlar tarafından ele alınmıştır:

4) Gzip, 32KB sözlükle aynı Deflate algoritmasını kullanır, bu nedenle png dosyaları 32KB'den büyükse eşleşmeler aynı olsalar bile algılanmaz. Bzip2, 900 KB'lık bir blok kullandığından bu açıdan daha iyidir. XZ, IIRC'nin varsayılan sıkıştırma düzeyinde 4 MB'lik bir sözlüğe sahip olduğu LZMA'yı kullanır. 5) Zip formatı katı sıkıştırma kullanmaz, bu nedenle benzer veya aynı dosyaları daha iyi sıkıştırmaz.

Belki PAQ veya PPMD ​​ailesinden kompresörler daha iyi sıkıştırır, ancak çok sayıda benzer görüntü dosyasını sıkıştırmanız gerekiyorsa, 3 yaklaşımı düşünebilirsiniz:

1) Görüntüleri sıkıştırılmamış olarak saklayın (PNG -0 ile veya sıkıştırma olmadan bir formatta) ve büyük sözlük veya blok boyutlu bir kompresörle sıkıştırın. (LZMA iyi çalışır)

2) Başka bir seçenek de filtreleri tutmak, ancak PNG'lerden Deflate sıkıştırmasını kaldırmak olabilir. Bu, örneğin ( AdvDef ) yardımcı programıyla yapılabilir. Sonra ortaya çıkan sıkıştırılmamış PNG'leri sıkıştırırsınız. Dekompresyondan sonra sıkıştırılmamış PNG'yi koruyabilir veya AdvDef ile tekrar sıkıştırabilirsiniz (ancak bu zaman alacaktır).

Hangisinin en çok sıkıştırdığını görmek için her iki yaklaşımı da test etmeniz gerekir.

3) Son seçenek, bir videodaki png görüntülerini dönüştürmek, kayıpsız x264 gibi kayıpsız bir video kompresörü ile sıkıştırmak (doğru renk formatını kullanarak özel dikkat göstererek) ve daha sonra çıkarma üzerine çerçeveleri bireysel png görüntülerine çıkarmak olacaktır. Bu ffmpeg ile yapılabilir. Ayrıca, kare numarası ile orijinal ad arasındaki eşlemeyi de tutmanız gerekir.

Bu en karmaşık yaklaşım olacaktır, ancak png'lerin tümü bir animasyonun parçasıysa en etkili yöntem olabilir. Ancak, gerekirse saydamlığı destekleyen bir video biçimine ihtiyacınız olacaktır.

Düzenleme: Ayrıca sık kullanılmaz MNG biçimi vardır.

Özel veri kümeleriniz olduğunda, çok amaçlı araçlar yerine özel algoritmalar kullanırsınız.

Cevap, seçtiğiniz kayıpsız kompresyonların yaptığınız şey için yapılmamasıdır. Hiç kimse aynı görüntüyü iki kez sıkıştırmanızı beklemez ve bunu yapsanız bile (yanlışlıkla) önceki tüm girişlere karşı kontrol etmek algoritmanızı O (n ^ 2) yapar (belki biraz daha iyi olur, ancak en azından naiv yaklaşımı n ^ olur) 2).

Test ettiğiniz sıkıştırma programlarınızın çoğu O (n) 'de çalışır, optimum sıkıştırma oranına göre hızı belirler. Kimse bilgisayarını 5 saat boyunca çalıştırmak istiyor, sadece birkaç MB, özellikle bu günlerde. Daha büyük girdiler için O (n) üzerindeki herhangi bir şey çalışma zamanı sorunu haline gelir.

Başka bir konu koç. Girişinizin yeterince büyük olduğu herhangi bir zamanda girişinizin her bölümüne erişemezsiniz. Bunu göz ardı etse bile, çoğu insan sadece bir şey sıkıştırmak için tüm koç veya cpu'larından vazgeçmek istemez.

Dosyalarınızda sıkıştırmak istediğiniz kalıplar varsa, bunlar üzerinde manuel işlemler yapmanız, kendi sıkıştırmanızı yazmanız veya potansiyel olarak bir "arşiv" tipi sıkıştırma (nano) kullanmanız gerekir. Günlük kullanım için çok yavaş olan uzun süreli depolama için bir sıkıştırma.

Başka bir seçenek de kayıpsız bir video sıkıştırma olabilir.

PNG dosya biçimi zaten DEFLATE sıkıştırma algoritmasını dahili olarak kullanıyor. Bu, bazı varyasyonlarda xz, gzip ve zip tarafından kullanılan algoritmanın aynısıdır. tar.gzve tar.xzdosyalar arasındaki benzerliktenzip .

Aslında, DEFLATE sıkıştırılmış dosyalar üzerinde DEFLATE sıkıştırması gerçekleştirirsiniz - bu yüzden dosyalar neredeyse orijinal boyutunu korur.

bzip2O (neredeyse) aynı dosyalara gelince programı (ayrıca ilgili algoritma) daha iyidir.

# 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