Kayıpsız sıkıştırma verilerinin sınırı nedir? (böyle bir sınır varsa)

Son zamanlarda sıkıştırma ile ilgili algoritmalar ile uğraşıyordum ve kayıpsız veri sıkıştırma ile elde edilebilecek en iyi sıkıştırma oranının hangisi olduğunu merak ediyordum .

Şimdiye kadar, bu konuda bulabildiğim tek kaynak Wikipedia idi:

Video, sayısallaştırılmış film ve ses gibi sayısallaştırılmış verilerin kayıpsız sıkıştırılması, tüm bilgileri korur, ancak verilerin gerçek entropisi nedeniyle nadiren 1: 2 sıkıştırmadan çok daha iyi sonuç verebilir .

Ne yazık ki, Wikipedia'nın makalesi bu iddiayı destekleyecek bir referans veya alıntı içermiyor. Ben bir veri sıkıştırma uzmanı değilim, bu yüzden bu konuda verebileceğiniz herhangi bir bilgiyi takdir ediyorum ya da beni Wikipedia'dan daha güvenilir bir kaynağa yönlendirebilirseniz.

Birisi sihirli numaranın neden tam olarak 1: 2 gibi göründüğünü ve örneğin 1: 1.1 veya 1:20 gibi görünmediğinden emin değilim.

Bunun bir nedeni, birçok tipik durumda sayısallaştırılmış verilerin neredeyse yarısının gürültü olması ve gürültünün (tanım gereği) sıkıştırılamamasıdır.

Çok basit bir deney yaptım:

• Gri bir kart aldım . Bir insan gözüne göre, düz, nötr bir gri karton parçası gibi görünüyor. Özellikle bilgi yoktur .

• Ve sonra normal bir tarayıcı aldım - tam olarak insanların fotoğraflarını dijitalleştirmek için kullanabileceği bir tür cihaz.

• Gri kartı taradım. (Aslında, gri kartı bir kartpostalla birlikte taradım. Kartpostal, kontrol yazılımı için, tarayıcı yazılımının garip bir şey yapmadığından emin olabilirdim, örneğin özelliksiz gri kartı gördüğünde otomatik olarak kontrast ekleyin.)

• Gri kartın 1000x1000 piksellik bir bölümünü kırptım ve gri skalaya (piksel başına 8 bit) dönüştürdüm.

Şu an sahip olduğumuz şey, taranmış bir siyah beyaz fotoğrafın özelliksiz bir parçasını, örneğin açık gökyüzünü incelediğinizde neler olduğuna oldukça iyi bir örnek olmalıdır . Prensip olarak, görülecek hiçbir şey olmamalıdır.

Bununla birlikte, daha büyük bir büyütme ile, aslında şöyle görünür:

Açıkça görülebilen bir desen yoktur, ancak düzgün bir gri rengi yoktur. Bunun bir kısmı büyük olasılıkla gri kartın kusurlarından kaynaklanıyor, ancak çoğunun sadece tarayıcı tarafından üretilen gürültü (sensör hücresindeki termal amplifikatör, amplifikatör, A / D dönüştürücü, vb.) Olduğunu varsayacağım. Gauss gürültüsüne benziyor; İşte histogram ( logaritmik ölçekte):

Şimdi eğer varsayalım her piksel kendi gölge bu dağıtımdan iid aldı sahip olduğunu, ne kadar entropi var? Python senaryom, piksel başına 3.3 bit entropi olduğunu söyledi . Ve bu çok fazla gürültü.

Eğer durum buysa, hangi sıkıştırma algoritmasını kullanırsak kullanalım, 1000x1000 piksel bitmap en iyi durumda 412500 baytlık bir dosyaya sıkıştırılacaktır. Ve pratikte ne olur: 432018 bayt PNG dosyası var, oldukça yakın.

Biraz fazla genelleştirirsek, bu tarayıcıyla hangi siyah beyaz fotoğrafları taradığım önemli değil, aşağıdakilerin toplamını alacağım:

• "yararlı" bilgiler (varsa),
• gürültü, yakl. Piksel başına 3 bit.

Sıkıştırma algoritmanız faydalı bilgileri piksel başına << 1 bit'e sıkıştırsa bile, sıkıştırılamaz gürültünün piksel başına 3 bit'e kadar sahip olacaksınız. Ve sıkıştırılmamış sürüm piksel başına 8 bittir. Böylece sıkıştırma oranı, ne yaparsanız yapın 1: 2'lik ballparkta olacaktır.

Aşırı idealize edilmiş koşulları bulma girişimi ile başka bir örnek:

• En düşük hassasiyet ayarını (en az gürültü) kullanan modern bir DSLR fotoğraf makinesi.
• Gri kartın odak dışı bir çekimi (gri kartta görünür bazı bilgiler olsa bile, bu bulanıklaşır).
• RAW dosyasının kontrast eklemeden 8 bit gri tonlamalı bir görüntüye dönüştürülmesi. Ticari bir RAW dönüştürücüsünde tipik ayarları kullandım. Dönüştürücü varsayılan olarak gürültüyü azaltmaya çalışır. Ayrıca, sonucu 8 bitlik bir dosya olarak kaydediyoruz - özünde, ham sensör okumalarının en düşük dereceli bitlerini atıyoruz !

Sonuç ne oldu? Tarayıcıdan aldığımdan çok daha iyi görünüyor; gürültü daha az belirgindir ve görülecek hiçbir şey yoktur. Bununla birlikte, Gauss gürültüsü oradadır:

Ve entropi? Piksel başına 2.7 bit . Uygulamada dosya boyutu mu? 1M piksel için 344923 bayt. Gerçekten en iyi senaryoda, bazı hile ile sıkıştırma oranını 1: 3'e ittik.

Tabii ki bunların hepsinin TCS araştırmasıyla bir ilgisi yok, ancak gerçek dünyayla sayısallaştırılmış verilerin sıkıştırılmasını gerçekten sınırlayan şeyin akılda tutulması iyi olduğunu düşünüyorum . Daha ince sıkıştırma algoritmaları ve ham CPU gücü tasarımındaki ilerlemeler yardımcı olmayacaktır; tüm gürültüyü kayıpsız bir şekilde kaydetmek istiyorsanız, 1: 2'den daha iyisini yapamazsınız.

Shannon'un gürültüsüz kodlama teoremini zaten biliyor musunuz ? Bu teorem kayıpsız sıkıştırma üzerine teorik sınırlar oluşturur. Diğerlerinin yorumlarından bazıları bu teoremi bildiğinizi varsayar, ancak sorudan, aradığınız cevap olabileceğini düşünüyorum.

$n>0$

1. $n$

2. Ortak pratik çözüm, kodlayacağınız tek tam sayının tümü 1 ile 256 arasındaysa (isterseniz 16, 32 ve 64 bite genelleme yapın) 8 bit kullanmaktır.

3. $n+1$$n$$n$

4. $\lceil\log_2 n\rceil$$\lceil\log_2 n\rceil+1$$n$$\lceil\log_2 n\rceil-1$$\lceil\log_2 n\rceil$$2\lceil\log_2 n\rceil-1$$n$$\lg n=\max(1,\lceil\log_2 n\rceil)$

5. Gama kodu, keyfi olarak birçok tamsayı için daha az alan ve sadece sınırlı bir miktar için daha fazla alan kullanan başka kodlar olduğu için en uygun değildir . Konu hakkında çok iyi bir okuma, 1976'dan Jon Louis Bentley ve Andrew Chi-Chih Yao tarafından "Sınırsız arama için neredeyse optimal bir algoritmadır" (Özellikle arama algoritmalarının karmaşıklığı ve tamsayı kodlamalarının boyutu arasındaki bağlantıyı seviyorum: I bildiğim en basit ve güzel TCS sonuçlarından birini bulun). Sonuç olarak, biti, en iyi çözümün iki , bu da daha iyi çözümlerin karmaşıklığı göz önüne alındığında, uygulamada en çok yeterli olanı kabul eder.$2\lceil\log_2 n\rceil-1$

6. Yine de, "fırsatçı" yaklaşımı sınırına getirerek, çeşitli hipotezlerden yararlanan sonsuz sayıda sıkıştırma şeması vardır. Fırsatçı kodlamaların bu sonsuzluğu (yani sıkıştırma şeması) ile başa çıkmanın bir yolu, hipotezin kendisinin kodlanmasını gerektirmek ve hipotezin kodlama boyutunu toplam sıkıştırma boyutunda hesaba katmaktır. Resmi olarak, bu hem sıkıştırılmış verileri hem de kod çözücüyü kodlamaya veya daha genel olarak yürütüldüğünde sıkıştırılmamış nesneyi çıkaran bir programı kodlamaya karşılık gelir : böyle bir programın en küçük boyutuna Kolmogorov'un karmaşıklığı denir . Bu, programın yürütme süresine bağlı kalmaksızın çok teorik bir yapıdır.$K$$K$hesaplanamaz. Bu kavramın etrafındaki kolay bir çözüm, Levin'in kendi sınırlayıcı programları tarafından verilir , burada yalnızca sınırlı yürütme süresi olan programları (örneğin, orijinal örneğin uzunluğunun sabit bir faktörü içinde olan, Her sembolü yazması gereken algoritmanın karmaşıklığı).

Kolmogorov'un karmaşıklığı ve varyantları hakkında çalışan bir topluluk var ve kayıpsız sıkıştırma üzerinde çalışan başka bir topluluk var (kullandığım tamsayılardaki örnek, diğer birçok veri türüne eşdeğerdir), yüzeyi zorlukla çizdim ve diğerleri hassasiyet ekleyebilir (Kolmogorov gerçekten benim uzmanlık alanım değil), ancak umarım bu, umduğunuz cevabı vermezseniz, sorunuzu netleştirmenize yardımcı olabilir :)

(sadece yorumumun bir uzantısı)

(Joe'nun cevabında işaret ettiği gibi) Shannon - 1948 tarihli makalesinde " Matematiksel İletişim Kuramı " veri sıkıştırma teorisini formüle etti ve kayıpsız veri sıkıştırma için temel bir sınır olduğunu tespit etti. Entropi oranı adı verilen bu sınır H ile gösterilir. H'nin kesin değeri bilgi kaynağına - daha spesifik olarak kaynağın istatistiksel doğasına bağlıdır. Kaynağı kayıpsız bir şekilde H'ye yakın sıkıştırma oranı ile sıkıştırmak mümkündür. H'den daha iyi yapmak matematiksel olarak imkansızdır.

Bununla birlikte, yüksek kontrastlı kenarları olmayan ve yumuşak seviye geçişleri olan bazı görüntü sınıfları (örneğin tıbbi gri tonlamalı görüntüler) sıkıştırılabilir (çok verimli değil).

JPEG-LS ve JPEG2000 , tıbbi görüntülerin kayıpsız depolanması için standartlar gibi görünmektedir. Sıkıştırma oranlarının karşılaştırması için bu tabloya bakın (JPEG-LS biraz daha iyi sıkıştırma sağlar).

"Kayıpsız tıbbi görüntü sıkıştırma" kullanarak size yardımcı olabilecek aşağıdaki makaleleri buldum:

Tıbbi görüntü sıkıştırma teknikleri üzerine yeni (2011) bir araştırma: İki Boyutlu Tıbbi Görüntü Sıkıştırma Teknikleri - Anket

... Bu makale iki boyutlu (2B) hareketsiz görüntüler için DCT, DWT, ROI ve Sinir Ağlarına dayalı çeşitli sıkıştırma tekniklerine genel bir bakış sunmaktadır.

İki standart kayıpsız sıkıştırma algoritmasının ayrıntılı bir sunumu: Kayıpsız modda JPEG-LS ve JPG2000: Gri Tonlamalı Tıbbi Görüntülerin Kayıpsız Sıkıştırılması - Geleneksel ve En Yeni Yaklaşımların Etkinliği

... Birden fazla anatomik bölge, yöntem ve satıcıdan üç bin, altı yüz yetmiş dokuz (3,679) tek kare gri tonlamalı görüntü test edildi. ...

Başka bir araştırma: Çağdaş Tıbbi Görüntü Sıkıştırma Teknikleri Araştırması

DÜZENLE

Belki de hala "Bir görüntünün entropisi nedir?" ... Tamam, görüntüdeki bilgi miktarı ... ama daha iyi anlamak için, görüntü sıkıştırmada genellikle kullanılan 3 aşama hakkında bir şeyler okumalısınız :

• dönüşümü (örneğin Ayrık Dalgacık Dönüşümü)
• niceleme
• entropi kodlaması

Google'ı Görüntü sıkıştırma hakkında bir eğitim veya kitap aramak için (örneğin hızlı bir eğitim ) kullanabilir veya çevrimiçi bir teknik video izlemeye çalışabilirsiniz (örneğin Ders 16 - Görüntü ve Video kodlamasına giriş ).

Bir dosyayı dize olarak düşünün.

Asla bir ipin Kolmogorov karmaşıklığından daha iyisini yapamazsınız (bu Komogorov karmaşıklığının tanımı ile).

Bir dize uzunluğunu düzeltin. Şimdi sadece n uzunluğuna bakıyoruz.

Bu tür dizelerin yarısı en fazla 1 bit sıkıştırılabilir. Tüm dizelerin 1 / 4'ü en fazla 2 bit ile sıkıştırılabilir. Tüm bu dizelerin 1 / 8'i en fazla 3 bit ile sıkıştırılabilir.

Böylece, dizelerin hangi kısmı (görüntüler, dosyalar vb.) 2: 1 oranında sıkıştırılabilir - çok, çok az. Peki neden sıkıştırma hiç işe yaramıyor? Gerçek insanların sıkıştırmaya çalıştığı neredeyse tüm veriler oldukça yapılandırılmış olduğundan, rastgele bir dosya gibi görünmüyor. Veriler ne kadar rasgele görünüyorsa sıkıştırmak o kadar zor olur. El ele giderler. Dizelerin çoğu rastgele görünür.

Bunu çalışırken görmek için, rastgele bir işlem kullanarak rastgele bir dosya oluşturun. Gerçekten, gerçekten rastgele bir dosya demek istiyorum. Şimdi sık kullandığınız sıkıştırma algoritmasını kullanarak sıkıştırmayı deneyin. Neredeyse her zaman aynı boyutta kalır veya büyür.

Kapak tarafında, yüksek oranda sıkıştırılabilir teller vardır. Şu dizeyi alın: 100000..000 (1'i ardından bir milyon sıfır). Tanımı önceki cümleye uyuyor ve bir bilgisayar onu bu tanımdan (ya da buna çok benzeyen bir şekilde) yeniden yapılandırabilir. Yine de bu açıklama bir milyon basamak uzunluğunda değil.

Gerçek şu ki, bu özelliğe sahip dizeler (yüksek oranda sıkıştırılabilir olma) olası tüm dizeler arasında son derece nadirdir. İkincisi, neredeyse tüm insan tarafından üretilen verilerin süper, süper sıkıştırılabilir olması, çünkü çok yapılandırılmış olmasıdır.