"(Sıkıştırma) doku sıkıştırma nasıl çalışır" büyük bir konudur. Umarım Nathan'ın cevabının içeriğini çoğaltmadan bazı görüşler sağlayabilirim .
Gereksinimler
Doku sıkıştırma tipik olarak Beers ve arkadaşlarının Sıkıştırılmış Dokulardan Oluşturma bölümünde ana hatlarıyla belirtildiği gibi, JPEG / PNG gibi 'standart' görüntü sıkıştırma tekniklerinden farklıdır :
Kod Çözme Hızı : Doku sıkıştırmasının, sıkıştırılmamış dokular kullanmaktan daha yavaş (en azından fark edilir şekilde değil) olmasını istemezsiniz. Aşırı donanım ve güç maliyetleri olmadan hızlı dekompresyon elde edilmesine yardımcı olabileceğinden, sıkıştırmanın açılması da nispeten basit olmalıdır.
Rasgele Erişim : Belirli bir oluşturma sırasında hangi metinlerin gerekli olacağını kolayca tahmin edemezsiniz. Erişilen metinlerin bazı alt kümeleri ( M) , örneğin görüntünün ortasından geliyorsa, M'yi belirlemek için dokunun 'önceki' satırlarının tümünü deşifre etmek zorunda değilsiniz ; JPEG ve PNG ile bu, piksel kod çözme, önceden kodu çözülmüş verilere bağlı olduğundan gereklidir.
Bunu söyledikten sonra, "rastgele" erişiminiz olduğu için, tamamen keyfi olarak örneklemeye çalışmanız gerektiği anlamına gelmez
Sıkıştırma Oranı ve Görsel Kalite : Beers ve ark. (İkna edici bir şekilde) sıkıştırma oranını iyileştirmek için sıkıştırılmış sonuçta bir miktar kalite kaybının faydalı bir değiş tokuş olduğunu iddia etmektedir. 3B oluşturmada, veriler muhtemelen manipüle edilecektir (örn. Filtrelenmiş ve gölgeli vb.) Ve bu nedenle bazı kalite kaybı maskelenebilir.
Asimetrik kodlama / kod çözme : Belki biraz daha tartışmalı olsalar da, kodlama işleminin kod çözme işleminden çok daha yavaş olmasının kabul edilebilir olduğunu iddia ederler. Kod çözmenin HW dolum hızlarında olması gerektiği göz önüne alındığında, bu genellikle kabul edilebilir. (PVRTC, ETC2 ve diğerlerinin maksimum kalitede sıkıştırılmasının daha hızlı olabileceğini kabul edeceğim)
Erken Tarih ve Teknikler
Doku sıkıştırmasının otuz yılı aşkın bir süredir var olduğunu öğrenmek bazılarını şaşırtabilir. 70'li ve 80'li yılların uçuş simülatörleri, nispeten büyük miktarlarda doku verilerine erişime ihtiyaç duydu ve 1980'de 1MB RAM'in> 6000 $ olduğu göz önüne alındığında , doku ayak izini azaltmak çok önemliydi. Başka bir örnek olarak, 70'lerin ortalarında, az miktarda yüksek hızlı bellek ve mantık bile, örneğin mütevazı 512x512 RGB çerçeve tamponu için yeterli ) küçük evin fiyatını geri alabilir.
Bununla birlikte, açıkça doku sıkıştırma olarak adlandırılmayan AFAIK, literatürde ve patentlerde aşağıdakileri içeren tekniklere referanslar bulabilirsiniz:
a. matematiksel / prosedürel doku sentezinin basit formları,
b. daha sonra doku başına RGB değeri ile çarpılan tek kanallı bir dokunun (örneğin 4bpp) kullanılması,
c. YUV ve
d. paletler ( Heckbert'in sıkıştırma yapmak için yaklaşımının kullanılmasını öneren literatür )
Görüntü Verilerini Modelleme
Yukarıda belirtildiği gibi, doku sıkıştırması neredeyse her zaman kayıplıdır ve bu nedenle sorun, daha az önemli bilgileri atarken önemli verileri kompakt bir şekilde temsil etmeye çalışmaktan biri haline gelir. Aşağıda tarif edilecek olan çeşitli şemaların tümü, doku verilerinin ve gözün tepkisinin tipik davranışına yaklaşan örtük bir 'parametreli' modele sahiptir.
Ayrıca, doku sıkıştırması sabit oranlı kodlama kullanma eğiliminde olduğundan, sıkıştırma işlemi genellikle modele beslendiğinde orijinal dokuya iyi bir yaklaşım oluşturacak parametre setini bulmak için bir arama adımı içerir. Ancak bu arama adımı zaman alıcı olabilir.
( Optipng gibi araçlar hariç , bu, PNG ve JPEG'in tipik kullanımının doku sıkıştırma şemalarından farklı olduğu başka bir alandır)
Daha fazla ilerlemeden önce, TC'nin daha iyi anlaşılmasına yardımcı olmak için, veri sıkıştırma için çok yararlı bir matematik aracı olan Temel Bileşen Analizi'ne (PCA) bir göz atmaya değer .
Örnek doku
Çeşitli yöntemleri karşılaştırmak için aşağıdaki resmi kullanacağız:
Bunun, RGB renk küpünün çoğunu kapsadığı ve piksellerin sadece% 15'inin tekrarlanan renkler kullandığından özellikle palet ve VQTC yöntemleri için oldukça zor bir görüntü olduğunu unutmayın.
PC ve (90'ların ortalarından sonra) Konsol Doku sıkıştırma
Veri maliyetlerini azaltmak için, bazı PC oyunları ve erken oyun konsolları da bir tür Vector Quantisation (VQ) olan palet görüntülerini kullanmıştır. Palet tabanlı yaklaşımlar, belirli bir görüntünün yalnızca RGB (A) renk küpünün nispeten küçük kısımlarını kullandığını varsayar. Palet dokuları ile ilgili bir sorun, elde edilen kalite için sıkıştırma oranlarının genellikle oldukça mütevazı olmasıdır. "4bpp" (GIMP kullanarak) sıkıştırılmış örnek doku
, bunun VQ şemaları için nispeten zor bir görüntü olduğunu tekrar unutmayın.
Daha büyük vektörlere sahip VQ (örn. 2bpp ARGB)
Beers ve arkadaşlarından esinlenilen Dreamcast konsolu, tek baytlı 2x2 hatta 2x4 piksel blokları kodlamak için VQ kullandı. Palet dokularındaki "vektörler" 3 veya 4 boyutlu olsa da, 2x2 piksel bloklarının 16 boyutlu olduğu düşünülebilir. Sıkıştırma şeması, bu vektörlerin yeterli, yaklaşık tekrarının olduğunu varsayar.
VQ ~ 2bpp ile tatmin edici bir kalite elde edebilse de, bu şemalarla ilgili sorun, bağımlı bellek okumaları gerektirmesidir: Piksel kodunu belirlemek için dizin haritasından ilk okumayı, ilişkili piksel verilerini gerçekten almak için bir saniye takip eder bu kodla. Ek önbellekler, ortaya çıkan bazı gecikmeleri hafifletmeye yardımcı olabilir, ancak donanıma karmaşıklık katar.
2bpp Dreamcast şeması ile sıkıştırılmış örnek görüntü
. Dizin haritası:
VQ verilerinin sıkıştırılması çeşitli yollarla yapılabilir, ancak IIRC , yukarıdaki, 16D vektörlerini ana vektör boyunca türetmek ve daha sonra iki temsili vektör ortalama kare hatasını en aza indirecek şekilde 2 sete bölmek için PCA kullanılarak yapıldı. İşlem daha sonra 256 aday vektör üretilinceye kadar tekrarlandı. Daha sonra temsilcileri geliştirmek için küresel bir k-ortalamaları / Lloyd algoritması yaklaşımı uygulandı.
Renk Alanı Dönüşümleri
Renk uzayı dönüşümleri de PCA'yı kullanarak, küresel renk dağılımının genellikle diğer eksenler boyunca çok daha az yayılmış olarak büyük bir eksen boyunca yayıldığını kaydeder. YUV gösterimleri için varsayımlar, a) ana eksenin genellikle luma yönünde olması ve b) gözün bu yönde değişikliklere karşı daha hassas olmasıdır.
3dfx Voodoo sistemi , her 8 bitlik texini 322 formatına bölen 8bpp'lik "Dar Kanal" sıkıştırma sistemi olan "YAB" sağladı ve RGB'ye eşlemek için bu verilere kullanıcı tarafından seçilen bir renk dönüşümü uyguladı. Ana eksen böylece 8 seviyeye ve her biri 4 olmak üzere daha küçük eksenlere sahipti.
S3 Virge yongası, kullanıcının tüm doku için 4bpp tek renkli bir doku ile birlikte ana eksende olması gereken iki uç renk belirtmesine izin veren biraz daha basit bir 4bpp şemasına sahipti . Piksel başına değer daha sonra, RGB sonucunu üretmek için uç renkleri uygun ağırlıklarla harmanladı.
BTC tabanlı şemalar
Birkaç yıl geri saran Delp ve Mitchell , Blok Kesme Kodlama (BTC) adı verilen basit (tek renkli) bir görüntü sıkıştırma şeması tasarladı . Bu makale aynı zamanda bir sıkıştırma algoritması içermekteydi, ancak bizim amacımız için esas olarak ortaya çıkan sıkıştırılmış veriler ve dekompresyon işlemi ile ilgileniyoruz.
Bu şemada, görüntüler tipik olarak 4x4 piksel bloklara bölünür, bunlar aslında bir lokalize VQ algoritması ile bağımsız olarak sıkıştırılabilir. Her blok, iki "değer", a ve b ve her piksel için iki değerden hangisini kullanacağını belirleyen bir 4x4 dizin biti ile temsil edilir .
S3TC : 4bpp RGB (+ 1 bit alfa)
Görüntü sıkıştırma için BTC'nin çeşitli renk varyantları önerilmiş olsa da, bizim için ilgi çekici olan Iourcha ve arkadaşlarının S3TC'si , bazıları Hoffert ve ark . Apple'ın Quicktime'ında kullanıldı.
DirectX varyantları olmayan orijinal S3TC, RGB veya RGB + 1 bit Alfa'nın bloklarını 4bpp'ye sıkıştırır. Dokudaki her 4x4 bloğun yerini iki uç renk alır ( A ve B) , bunlardan en fazla iki renk sabit ağırlıklı doğrusal karışımlarla türetilir. Ayrıca, bloktaki her bir texel, bu dört renkten birinin nasıl seçileceğini belirleyen 2 bitlik bir dizine sahiptir.
Örneğin, AMD / ATI Compressenator aracı ile sıkıştırılmış test görüntüsünün 4x4 piksellik bir bölümü aşağıdadır. ( Teknik olarak test görüntüsünün 512x512 sürümünden alınmıştır, ancak örnekleri güncellemek için zaman eksikliğimi affedin ).
Bu sıkıştırma işlemini gösterir: Renklerin ortalaması ve ana ekseni hesaplanır. Daha sonra, bu uç noktaların türetilmiş 1: 2 ve 2: 1 harmanlarıyla (veya bazı durumlarda 50:50 harmanıyla) elde edilen eksene `` yatan '' iki uç noktayı bulmak için en iyi uyum gerçekleştirilir. hatayı en aza indirir. Her orijinal piksel daha sonra sonucu üretmek için bu renklerden birine eşlenir.
Bu durumda olduğu gibi, renkler ana eksen tarafından yaklaşık olarak makul ise, hata nispeten düşük olacaktır. Bununla birlikte, aşağıda gösterilen komşu 4x4 bloğunda olduğu gibi, renkler daha farklıysa, hata daha yüksek olacaktır.
AMD Compressonator ile sıkıştırılmış örnek görüntü şunları üretir:
Renkler blok başına bağımsız olarak belirlendiğinden, blok sınırlarında süreksizlikler olabilir, ancak çözünürlük yeterince yüksek tutulduğu sürece, bu blok artefaktları fark edilmeyebilir:
VB1 : 4bpp RGB
Ericsson Doku Sıkıştırma da 4x4 bloklarla çalışır, ancak YUV gibi, yerel bir metin grubunun ana ekseninin genellikle "luma" ile çok güçlü bir şekilde ilişkili olduğunu varsayar. Daha sonra tekstiller grubu, ortalama bir renk ve bu varsayılan eksen üzerine tekstillerin izdüşümünün oldukça nicelenmiş, skaler bir 'uzunluğu' ile temsil edilebilir.
Bu, S3TC'ye göre veri depolama maliyetlerini azalttığından, ETC'nin bir bölümleme şeması sunmasına izin verir, böylece 4x4 bloğu, bir çift yatay 4x2 veya dikey 2x4 alt bloğuna bölünür. Bunların her birinin kendi ortalama rengi vardır. Örnek görüntü üretir:
Gaganın etrafındaki alan aynı zamanda 4x4 blokların yatay ve dikey bölümlerini gösterir.
Küresel + Yerel
Ivanov ve Kuzmin'in dağıtılmış paletlerinin veya PVRTC'nin yöntemi gibi küresel ve yerel şemalar arasında çapraz olan bazı doku sıkıştırma sistemleri vardır .
PVRTC : 4 ve 2 bpp RGBA
PVRTC, (pratikte, bilinearly) yükseltilmiş bir görüntünün, tam çözünürlük hedefine iyi bir yaklaşım olduğunu ve yaklaşık değer ile hedef, yani delta görüntü arasındaki farkın yerel olarak tek renkli olduğunu varsayar; baskın bir ana eksene sahiptir. Ayrıca, yerel ana eksenin görüntü boyunca enterpole edilebileceğini varsayar.
(yapılacaklar: Arıza gösteren resimler ekleyin)
PVRTC1 4bpp ile sıkıştırılmış örnek doku:
gaganın etrafındaki alanla:
BTC şemalarıyla karşılaştırıldığında, blok artefaktlar tipik olarak ortadan kaldırılır, ancak bazen kaynak görüntüde güçlü kesintiler varsa, örneğin "aşma" olabilir Lori'nin kafası silüeti.
2bpp varyantı, doğal olarak, 4bpp'den daha yüksek bir hataya sahiptir (boynun yakınındaki mavi, yüksek frekanslı alanlarda hassasiyet kaybına dikkat edin), ancak tartışmasız hala makul kalitede:
Dekompresyon maliyetleri hakkında bir not
Yukarıda tarif edilen şemaların sıkıştırma algoritmalarının orta ila yüksek değerlendirme maliyeti olmasına rağmen, dekompresyon algoritmaları, özellikle donanım uygulamaları için, nispeten ucuzdur. Örneğin ETC1, birkaç MUX ve düşük hassasiyetli toplayıcıdan biraz daha fazlasını gerektirir; S3TC, harmanlamayı gerçekleştirmek için etkili bir şekilde biraz daha fazla ilave birim; ve PVRTC, biraz daha. Teorik olarak, bu basit TC şemaları bir GPU mimarisinin filtreleme aşamasından hemen öncesine kadar dekompresyondan kaçınmasına izin verebilir, böylece dahili önbelleklerin etkinliğini en üst düzeye çıkarabilir.
Diğer Şemalar
Belirtilmesi gereken diğer yaygın TC modları şunlardır:
ETC2 - 'luma' ile iyi hizalanmayan renk dağılımları olan bölgelerin işlenmesini iyileştiren ETC1'in (4bpp) bir üst kümesidir. Ayrıca 1 bit alfa destekleyen bir 4bpp varyantı ve RGBA için 8bpp formatı vardır.
ATC - S3TC üzerinde etkili bir şekilde küçük bir varyasyon .
FXT1 (3dfx), S3TC temasının daha iddialı bir çeşidiydi .
BC6 ve BC7: ARGB'yi destekleyen 8bpp, blok tabanlı bir sistem. HDR modlarının yanı sıra, bunlar görüntü renk dağılımını daha iyi modellemeye çalışmak için ETC'ninkinden daha karmaşık bir bölümleme sistemi kullanır.
PVRTC2: 2 ve 4bpp ARGB. Bu, görüntülerdeki güçlü sınırlarla sınırlamaların üstesinden gelmek için biri de dahil olmak üzere ek modlar sunar.
ASTC: Bu aynı zamanda blok tabanlı bir sistemdir, ancak çok çeşitli bpp'yi hedefleyen çok sayıda olası blok boyutuna sahip olması nedeniyle biraz daha karmaşıktır. Ayrıca, sözde rasgele bir bölüm üretecine sahip 4 adede kadar bölüm bölgesi ve dizin verileri ve / veya renk hassasiyeti ve renk modelleri için değişken çözünürlük gibi özellikler içerir.