簡介

貼圖為圖形顯示效果增添了豐富的表現(xiàn)與細(xì)節(jié)，是增強圖形效果真實性與美觀性的重要元素详民，但同時由于包含了大量的信息延欠，貼圖對于游戲的各項性能指標(biāo)如內(nèi)存占用，帶寬等的影響也不容忽視阐斜，尤其是帶寬，當(dāng)代計算平臺如GPU/CPU多采用共享統(tǒng)一內(nèi)存框架诀紊，unified memory architecture谒出，而且由于多核CPU與GPU多線程運算的原因，對于帶寬的要求與壓力被進(jìn)一步放大邻奠，而這些影響在移動端上尤為突出笤喳。如何使用盡可能少的數(shù)據(jù)，盡可能低的性能損耗實現(xiàn)最佳的圖形表現(xiàn)碌宴，也就是所謂的高壓縮比杀狡，高保真（可實現(xiàn)對任一位置的像素數(shù)據(jù)隨機讀取）贰镣，就成為了貼圖壓縮算法的首要指標(biāo)呜象。（準(zhǔn)確來說膳凝，貼圖壓縮需要兼顧內(nèi)存，質(zhì)量恭陡，電量消耗（電量消耗的首要因素在于圖形渲染點亮屏幕蹬音，其次在于內(nèi)存access）以及表現(xiàn)這四項內(nèi)容）

當(dāng)前各路設(shè)備都已經(jīng)支持了實時貼圖采樣渲染功能，為了實現(xiàn)這個功能休玩，需要解決兩個問題：

貼圖數(shù)據(jù)在內(nèi)存的存儲消耗
數(shù)據(jù)傳輸?shù)膸捪?/li>

目前對于這兩個問題的主要解決方案是采用貼圖壓縮的方式來降低各種消耗著淆，而一個好的壓縮算法需要滿足以下四點：

較高的解碼速度
編碼結(jié)果可以實現(xiàn)隨機讀取
高保真，高壓縮率
較高的編碼速度

對于常見的各種壓縮貼圖格式如JPG等拴疤，其主要的缺陷是不能實現(xiàn)在壓縮狀態(tài)的直接隨機讀取永部，需要將數(shù)據(jù)完整的解壓縮到內(nèi)存中之后，才能完成數(shù)據(jù)讀取呐矾。同樣苔埋，一些‘變換編碼’壓縮算法如離散余弦變換DCT由于解碼速度慢，同時偶爾也會導(dǎo)致一些解碼結(jié)果的偏差如在尖角邊緣產(chǎn)生環(huán)狀紋路等（這種情況在貼圖中含有直線或者文字類型要素時比較明顯）

使用的最頻繁的貼圖壓縮算法凫佛，應(yīng)該要數(shù)調(diào)色板式的索引壓縮方法了讲坎，這種方法屬于vector quantisation（VQ）的一種，簡單來說愧薛，就是用幾個bit來表示一個像素晨炕，這個bit存儲的是一個索引值，用來表示某個lut上像素的位置毫炉，DXT系列的貼圖采用的就是這類壓縮算法瓮栗。這類調(diào)色板壓縮算法存在一些缺陷：

解壓縮算法需要重定位數(shù)據(jù)訪問，即根據(jù)索引指向來讀取對應(yīng)的數(shù)據(jù)結(jié)果瞄勾，在這個過程中需要涉及到兩次數(shù)據(jù)讀取费奸，第一次是索引，第二次是索引指向的數(shù)據(jù)进陡，從而導(dǎo)致訪問速度的降低愿阐，同時由于由于多個像素可能共用一張lut，會導(dǎo)致內(nèi)存數(shù)據(jù)訪問的競爭趾疚，這種情況在多個數(shù)據(jù)訪問同時發(fā)生的時候尤為嚴(yán)重
這類算法對于平常的filtering過程是不支持的缨历，因為索引插值得到的結(jié)果可能是錯誤的，而且調(diào)色板插值將導(dǎo)致原有的索引系統(tǒng)完全崩潰糙麦，而如果只對索引進(jìn)行插值辛孵，而調(diào)色板維持不變，將會導(dǎo)致貼圖放大后的結(jié)果呈現(xiàn)塊狀表現(xiàn)赡磅。
壓縮率低魄缚。

上圖給出了幾種主流的貼圖格式以及對應(yīng)的尺寸占用，這里是圖片來源焚廊。

目前移動端上的主流貼圖壓縮算法主要包含了以下幾種：

PVRTC系列
PVRTC
PVRTC2
ASTC
ETC系列
ETC1
ATITC
S3TC（也即DirectX TC系列）

雖然常用的貼圖格式如PNG/JPG具有比上述壓縮算法高得多的壓縮率與還原質(zhì)量冶匹，但是由于這些貼圖的壓縮率指的是在硬盤上的存儲數(shù)據(jù)量习劫，在內(nèi)存中需要全部重新展開，而展開后的數(shù)據(jù)量并沒有減少徙硅，對于沒有顯卡硬件支持的情況下榜聂，用壓縮格式保存紋理沒什么意義，特別是對于手持移動設(shè)備來說嗓蘑，解碼象JPG這種復(fù)雜格式對電量的消耗是很大的须肆，從而此處不再將這類壓縮算法納入考量。下面將針對上述這些算法的表現(xiàn)做進(jìn)一步的敘述

PVRTC - Power VR Texture Compression

顧名思義桩皿，這個壓縮格式是Imagination公司專門為PowerVR顯卡系列開發(fā)的圖形壓縮格式豌汇，這種格式可以避免block-based壓縮方法如ETC1等導(dǎo)致的矩形區(qū)域的不連貫。block-based壓縮方法將貼圖看成多個獨立的block泄隔，并對各個block分別進(jìn)行壓縮拒贱，而PVR采用的策略則是用兩張低分辨率的貼圖來表征原來的貼圖，在實際使用的時候佛嬉，將這兩張貼圖分別進(jìn)行上采樣恢復(fù)到原貼圖分辨率尺寸逻澳，之后進(jìn)行混合得到一張全分辨率低精度的調(diào)制結(jié)果。

PVRTC實現(xiàn)的基本思路是采用兩張或者多張低分辨率貼圖（通常1/4或者1/8大信弧）與一張高分辨率低精度（通常2bpp）的調(diào)試貼圖斜做，實現(xiàn)對原貼圖的模擬。因為低分辨率貼圖的低頻信息湾揽，可以得到如下的優(yōu)勢：

最終還原解壓縮得到的貼圖數(shù)據(jù)不會出現(xiàn)block-based壓縮算法而出現(xiàn)的塊狀不連續(xù)問題瓤逼；
解壓縮過程速度快，這是因為解碼時采用的是固定速率的（fixed-rate）調(diào)制方式库物，而不需要涉及到重定位數(shù)據(jù)訪問（inidirect data access）

PVRTC的基本算法實現(xiàn)：

對原始數(shù)據(jù)進(jìn)行一次低通濾波（基于linear wavelet transform）霸旗，取得低頻系數(shù)，并進(jìn)行一次4x4的upscale上采樣
將原始貼圖數(shù)據(jù)與變換后的貼圖數(shù)據(jù)做差戚揭，得到delta數(shù)據(jù)
對delta貼圖進(jìn)行axis分析诱告，計算得到每個像素對應(yīng)的principal axis vector，并對此vector進(jìn)行flip民晒，使得與neighbor的vector保持一致（這根軸跟原貼圖的軸是不同的精居，而且基本上可以看成是近似垂直的）
將axis vector數(shù)據(jù)貼圖進(jìn)行filter之后，將vector與delta數(shù)據(jù)做點乘镀虐，根據(jù)結(jié)果的符號判斷此時應(yīng)該取用原貼圖對應(yīng)位置的像素顏色還是取用濾波后的貼圖顏色數(shù)值減去delta顏色數(shù)值箱蟆，從而得到全分辨率的初始低通貼圖A或者B沟绪，
之后通過循環(huán)調(diào)優(yōu)的方式來優(yōu)化結(jié)果：簡單來說就是根據(jù)一定的規(guī)則設(shè)置合適的modulation的數(shù)值刮便，并根據(jù)調(diào)制后的數(shù)據(jù)結(jié)果與原貼圖數(shù)據(jù)偏差計算新版的低通貼圖A或者B，并重復(fù)上述步驟

其解壓過程示意圖如下（按照這種示意圖绽慈，S3TC可以理解為這種壓縮算法的一個變種恨旱，只要將調(diào)制信號改成1bit辈毯，true/false用來判斷使用哪個貼圖的結(jié)果作為最終的結(jié)果）：

將低分辨率貼圖上采樣4x4之后，得到模糊的原分辨率貼圖
跟據(jù)調(diào)制信號對多張貼圖的采樣結(jié)果進(jìn)行插值混合搜贤，并將結(jié)果輸出

PVRTC提供了兩種壓縮模式谆沃，分別是8：1的4bpp（4 byte/pixel）模式與16：1的2bpp模式，并且PVR同時支持RGB與RGBA的數(shù)據(jù)壓縮格式仪芒，而即使使用的是RGBA壓縮格式唁影，也只是對有需要的alpha數(shù)據(jù)進(jìn)行存儲，對于沒有必要的alpha數(shù)據(jù)掂名，只存儲了RGB數(shù)據(jù)据沈，極大的避免了浪費。

PVRTC - 4bpp饺蔑，壓縮數(shù)據(jù)包含了M/4 × N/4個block（M,N是原貼圖的尺寸大行拷椤），每個block包含了2個color數(shù)據(jù)（來源于之前提到的兩張低分辨率貼圖猾警，如果是多張孔祸，那么此處將有多個），1個mode bit（指明是否具有alpha发皿？）崔慧，以及用來給4x4個像素做插值的調(diào)試數(shù)據(jù)。對于這種數(shù)據(jù)格式而言雳窟，每個block都可以有獨立的alpha標(biāo)志尊浪，據(jù)此可以進(jìn)行不同的解碼得到不同精度和結(jié)果的數(shù)據(jù)，如具有alpha的封救，精度會有所降低拇涤。

為了增加硬件層的數(shù)據(jù)重用，低分辨率貼圖的顏色數(shù)據(jù)在初始化的時候編碼被擴展成ARGB4555（原來是1位表征alpha）誉结，對于不透明物件來說前面4位數(shù)值為0xF鹅士，而對于透明/半透物件來說，第一位為0惩坑，后續(xù)三位用來表征透明程度掉盅。為了降低硬件消耗，接下來先使用線性插值完成上采樣以舒，之后再將結(jié)果轉(zhuǎn)換到ARGB8趾痘，而不是反過來，而這種順序的顛倒是不影響結(jié)果的（因為轉(zhuǎn)換只是做了一個與常數(shù)的乘法蔓钟，而這個乘法可以移到外面）永票。

32bit的調(diào)試數(shù)據(jù)可以分割成16個2bpp數(shù)據(jù)，每個數(shù)據(jù)可以表示四個數(shù)值，根據(jù)modulation mode的不同可以對應(yīng)于不同的數(shù)值:

默認(rèn)標(biāo)準(zhǔn)Mod Mode為0侣集，則此時00,01,10,11分別對應(yīng)0/8键俱，3/8， 5/8世分，8/8四個數(shù)值编振，用以對兩張color貼圖的value進(jìn)行混合。設(shè)置這四個參數(shù)的原因有兩方面的考慮：

權(quán)重數(shù)值簡單臭埋，實現(xiàn)起來方便
一般認(rèn)為調(diào)試參數(shù)的分布通常與normal distribution的形狀保持一致踪央，所以考慮將這些數(shù)據(jù)稍微向著中心傾斜？

如果Mod Mode為1瓢阴，則此時對應(yīng)的是0/8杯瞻，4/8，4/8炫掐，8/8四個數(shù)值魁莉。在這種情況下有一個特殊處理的case，就是當(dāng)modulation數(shù)值為10的時候募胃，此時會強制alpha為0旗唁，雖然如S3TC那樣設(shè)置punch through texels為black是很常見的，但是這樣會導(dǎo)致在filtering的時候物件邊緣處出現(xiàn)不想要的halos（光暈痹束，漏光检疫？），所以祷嘶，為了避開這個問題屎媳，通過設(shè)置alpha為0來只選擇兩個低分辨率貼圖color的其中一個作為最終輸出結(jié)果。

Imagination公司推出的升級版PVRTC算法PVRTC2壓縮模式依然分為4bpp與2bpp兩種论巍，但是壓縮質(zhì)量有所提升烛谊。

PVRTC的優(yōu)勢與不足：

優(yōu)點：

支持RGBA
根據(jù)需要，有4bpp與2bpp兩種不同壓縮率的壓縮選項
在PowerVR硬件設(shè)備上有優(yōu)化加成

不足：

只有PowerVR硬件才能支持嘉汰？
只有2的冪次方尺寸的正方形貼圖才有比較好的表現(xiàn)兼容性丹禀？
壓縮速度較慢
壓縮帶alpha貼圖效果很差

S3TC - S3 Texture Compression

S3TC是一種block-based的壓縮算法，這種算法也有另外一種稱呼DXTC鞋怀，這是PC時代使用最廣泛的貼圖壓縮算法双泪，其與其他塊狀壓縮算法的區(qū)別在于，每個4x4色塊通常具有一個主軸（其實就是顏色變化方向）密似，這樣圍繞這個主軸焙矛，就可以假設(shè)所有的像素都落在這條主軸附近，從而只需要根據(jù)主軸兩個端點的顏色做線性插值得到其他顏色數(shù)據(jù)残腌，所以可以得到相較于其他塊狀壓縮算法更高的壓縮率村斟。

這種算法在每個色塊中的信噪比是恒定的（壓縮率也是固定的）剪返。且大的顏色誤差容易出現(xiàn)在顏色變化劇烈的區(qū)域以及塊狀邊緣。

S3TC有5種不同的壓縮算法邓梅，對應(yīng)于DXT1～DXT5，不過一般只有DXT1邑滨，DXT3日缨，DXT5得到的應(yīng)用比較廣泛。

DXT1：這是S3TC中具有最高壓縮率的壓縮方式掖看，這種壓縮算法可以將16個像素組成的一個block壓縮成一個64bit的數(shù)據(jù)匣距，這個64bit的數(shù)據(jù)由2個不同的16bit顏色數(shù)據(jù)（565）以及4x4個2bit的索引數(shù)據(jù)組成。

DXT1可以表示不透或者完全透明的貼圖數(shù)據(jù)哎壳，當(dāng)color_0數(shù)據(jù)比color_1大毅待，那么此時貼圖表示的數(shù)據(jù)是不透明的，否則則帶有一位透明標(biāo)志归榕。16個2位索引則表明了這4×4個像素塊所在像素的顏色值尸红，2位可以表示4種狀態(tài)，這4種狀態(tài)對應(yīng)于color_0刹泄，color_1以及在不透情況下通過均勻插值計算得到的color_2和color_3外里，在透明情況下，插值得到的color_2特石，而color_3用來表示透明盅蝗。

將16個像素組成的block壓縮成一個128bit的數(shù)據(jù)，其中64bit用來存儲alpha數(shù)據(jù)（前面64bit）姆蘸，而另外64bit用來如DXT1一樣表示color數(shù)據(jù)（后面64bit）

DXT2與DXT3中存儲的alpha數(shù)據(jù)是直接的16個4bit alpha數(shù)據(jù)墩莫，不需要如DXT1中的顏色數(shù)據(jù)一般另作間接索引

DXT2：DXT2中的顏色數(shù)據(jù)已經(jīng)完成了Premultiplied by alpha操作，即在color_0與color_1中存儲的數(shù)據(jù)是已經(jīng)進(jìn)行了alpha加成處理的逞敷？在后續(xù)使用時如果alpha發(fā)生變化狂秦，只需要改變這兩個顏色的數(shù)值，不需要再單獨復(fù)合推捐。故痊。。
DXT3：其中的顏色數(shù)據(jù)與alpha數(shù)據(jù)是單獨存儲的玖姑，沒有所謂的混合愕秫，等使用的時候需要取出來參與計算

DXT4與DXT5中的alpha數(shù)據(jù)則是如DXT1中的顏色數(shù)據(jù)一樣，需要另外索引得到焰络，不同的是戴甩，64bit數(shù)據(jù)被分割成2個8bit的alpha數(shù)據(jù)，和16個3bit的索引數(shù)據(jù)闪彼，可以表示8種不同透明層度甜孤。跟DXT1一樣协饲，根據(jù)alpha_0與alpha_1的大小關(guān)系，有不同的編碼實現(xiàn)缴川，當(dāng)alpha_0>alpha_1時茉稠，對alpha_0與alpha_1進(jìn)行插值，得到6個中間值把夸；否則對alpha_0與alpha_1進(jìn)行插值而线，得到4個中間值，而剩下的alpha_6與alpha_7分別賦值0與255.
DXT4：顏色數(shù)據(jù)已經(jīng)完成了Premultiplied by alpha操作
DXT5：與DXT3相同恋日，顏色與alpha獨立

優(yōu)點：

壓縮速度與解壓速度不慢
有廣泛的平臺支持

缺點：

并不是所有的android都能支持

ETC - Ericsson Texture Compression

ETC是Khronos專門為ES2.0設(shè)計的貼圖壓縮格式膀篮，其算法與S3TC一樣，都是block-based的岂膳，目前ETC有兩種版本：ETC1與ETC2誓竿。其基本原理給出如下：

首先制定某個block（2x4）的基色（base color），如下圖中的藍(lán)色圓圈所示
由于人眼對于亮度luminance的敏感度高于色度chrominance的敏感度谈截，所以ETC將按照luminance的主軸方向?qū)Ω鱾€像素進(jìn)行編碼

編碼完成后的結(jié)果如下圖所示筷屡，在需要的時候?qū)lock-basecolor與pixel-luminance結(jié)合，就可以得到解碼結(jié)果：

在各個block中的各個像素的luminance分布接近一條直線的時候簸喂，這種方法可以得到比較好的解碼質(zhì)量速蕊，但是如果各個像素的luminance分布比較散亂，結(jié)果就會比較糟糕了娘赴，此外规哲，如果某個block落在兩個顏色中間，而這個block中的像素luminance都是比較接近的诽表，那么經(jīng)過編碼解碼得到的block就會偏向于某種顏色唉锌，從而出現(xiàn)過渡區(qū)域的塊狀鋸齒。

ETC1是OpenGL ES的標(biāo)準(zhǔn)竿奏，但是不是OpenGL ES2.0的標(biāo)準(zhǔn)袄简，所以在OpenGL ES2.0中需要檢查是否支持ETC1，ETC1支持對24位RGB貼圖的壓縮泛啸，但是不支持對帶有alpha通道的貼圖的壓縮绿语，4bpp，也不支持單獨的R通道或者RG通道貼圖壓縮候址；

ETC2是ES3標(biāo)準(zhǔn)里的格式吕粹，具有與ETC1相同的屬性與壓縮率，但是擁有更高的質(zhì)量（Peak Signal to Noise Ratio：1.0db better than ETC1, 0.8db better than S3TC, 1.6db better than PVRTC)岗仑，且對alpha貼圖支持比較好匹耕，提供了類似DXT3與DXT5的完整alpha支持的8bpp壓縮模式與1bit alpha的4bpp壓縮模式，此外還提供了EAC格式荠雕，可以支持對單個通道或者兩個通道R/RG的數(shù)據(jù)壓縮稳其。其缺點在于壓縮工具的壓縮速率過低驶赏。

ETC2是向下兼容的，即可以使用加載ETC2的方式加載一張ETC1的貼圖既鞠，且可以正確解碼煤傍，另外可以將ETC1與ETC2貼圖存儲在一張貼圖文件中（參考文獻(xiàn)）。

ETC2有多個模式：

T Mode：適用于具有兩種不同chrominance堆的情況嘱蛋，每個block存儲兩個基色蚯姆，并根據(jù)第一個顏色沿著luminance intensity direction方向計算出額外的兩個顏色值，如下圖所示：

H Mode: 適用于具有兩組luminance intensity分布的情況浑槽，如下圖所示，最終分別存儲兩個基色數(shù)值返帕，之后對這兩個基色按照intensity方向進(jìn)行調(diào)制桐玻，最終的四個顏色值被用來解碼，還原原始圖像：

跟T Mode一樣荆萤，H Mode需要59bits镊靴，但是不同的是，這59bits中只有58bits是有效的链韭，剩余一位用作標(biāo)志偏竟，0表示第一個顏色是最暗的顏色，1表示第一個顏色是最亮的顏色敞峭。

Planar Mode：對于一些顏色變化不明顯的block踊谋，使用ETC或者S3TC的方式是不適合的，這種情況可以使用planar mode來存儲數(shù)據(jù)旋讹，如下圖所示殖蚕，每個block存儲3個RGB676的顏色，最終的解碼使用插值得到（三個顏色奠定兩個坐標(biāo)軸）

ETC下有兩種貼圖格式沉迹，KTX與PKM：

KTX是標(biāo)準(zhǔn)的Khronos壓縮格式睦疫，這種格式的容器可以同時容納多張貼圖紋理數(shù)據(jù)，當(dāng)使用KTX存儲Mipmap數(shù)據(jù)時鞭呕，只需要一張KTX就可以實現(xiàn)多級Mipmap數(shù)據(jù)的存儲蛤育。
相對于KTX的靈活與大容量而言，PKM是一種比較簡單的貼圖格式葫松，只能容納一張壓縮貼圖數(shù)據(jù)瓦糕，用這種格式存儲mipmap的時候，將會創(chuàng)建多張貼圖用以完成數(shù)據(jù)存儲腋么，這種方式效率較低刻坊，所以，如果使用mipmap党晋，必須要考慮使用KTX

優(yōu)勢：

相對于PNG來說谭胚，貼圖數(shù)據(jù)量有所減少
所有的android設(shè)備都能兼容

劣勢：

貼圖質(zhì)量有所損失
ETC1不支持alpha數(shù)據(jù)壓縮
ETC2壓縮速度慢

ASTC - Adaptive Scalable Texture Compression

ASTC是block-based的壓縮實現(xiàn)算法徐块，每個block占用128bit，但是與S3TC不同的是灾而，不同壓縮格式下胡控，每個block表示的像素塊大小是可以伸縮的，支持使用不同的ASTC壓縮率對貼圖進(jìn)行壓縮旁趟，范圍從4x4（8bpp）到12x12（0.89bpp）不等昼激，而且，對于每個block锡搜，都可以有自己的編碼方式與權(quán)重（此外橙困，對于block的尺寸也不僅限于POT，比如可以是6x5的（這種情況會為像素到block的歸屬查詢增加一些困難耕餐，不過由于所有block的尺寸都可以總結(jié)為3,5以及POT的乘法結(jié)果凡傅，按照這個結(jié)論進(jìn)行計算，也不會再增加太多麻煩[6]）肠缔，而每個block壓縮后的數(shù)據(jù)長度是128bits夏跷，因此對于同一種壓縮格式下，雖然各個block會采用不同的壓縮策略明未，但是最終的壓縮率都是相同的）槽华，所以可以根據(jù)貼圖數(shù)據(jù)進(jìn)行自適應(yīng)壓縮。通常采用6x6（3.56bpp）一檔的壓縮策略趟妥，壓縮質(zhì)量高過PVRTC 4bpp猫态。

雖然block尺寸越大，貼圖壓縮率越高披摄，但是過高的block尺寸也會有問題懂鸵，拋開因此導(dǎo)致的質(zhì)量下降不提，大尺寸的block在帶寬的消耗上回比小尺寸block要高行疏，因為在讀取某個像素的數(shù)據(jù)的時候會需要將整個block數(shù)據(jù)讀取進(jìn)來進(jìn)行解碼匆光，帶來了一定程度的浪費，這在使用過程中需要有所考慮[6]酿联。

每個block的前6個bits用于指定block模式终息，不同模式對應(yīng)不同的權(quán)重數(shù)目（以及這些權(quán)重所能取用的數(shù)值范圍），高比特率壓縮模式（block包含顏色比較復(fù)雜時）可以為每個像素指定一個權(quán)重贞让，比如8x8 block模式下周崭，有兩種支持64個權(quán)重的壓縮模式，其中一種模式的權(quán)重用于在兩種顏色中進(jìn)行選擇（只需要一個bit）喳张，另外一種模式則支持在3中顏色中進(jìn)行選擇（需要1.6個bits）续镇。低比特率壓縮模式（顏色比較一致的）block中，可以指定少一點的權(quán)重數(shù)目销部，比如8x8 block模式下摸航，總共有六種不同的權(quán)重壓縮模式制跟，這六種壓縮模式都包含12個權(quán)重值，分別對應(yīng)2,3,4,5,8,16種顏色選擇酱虎。在這種稀疏權(quán)重編碼模式下雨膨，每個權(quán)重會對應(yīng)到特定的像素上，其余沒有對應(yīng)權(quán)重的像素則需要從前后兩個具有權(quán)重的像素中插值出對應(yīng)的權(quán)重读串。

與DXTC一樣聊记，每個block都包含兩個插值端點(end points)，但是不同的是恢暖，插值端點可能不一定包含所有的通道（RGBA）排监，可能只包含其中部分通道（比如RG），這樣就可以實現(xiàn)對不同格式的貼圖進(jìn)行不同的壓縮（比如法線貼圖杰捂，alpha貼圖等）模式以得到更好的壓縮質(zhì)量舆床。

對于端點而言，也并不只是只有一種編碼方式[6]琼娘，其編碼方式主要有三種：

independent峭弟，直接存儲兩個端點的顏色數(shù)值A(chǔ),B附鸽，這種是最簡單的編碼模式脱拼，解壓的時候使用Aweight+B(1-weight)方式進(jìn)行
base+offset，對于一些數(shù)值比較大的情況坷备，直接存儲兩個端點顏色熄浓，精度可能不太夠，此時可能會采用在base上使用較大的位數(shù)進(jìn)行存儲省撑，在offset上分配較少位數(shù)赌蔑，之后解壓縮的時候，使用base+weight*offset的方式得到數(shù)值
base+scale竟秫，對于一些顏色分布在luminance軸線上的情況娃惯，可以通過將顏色編碼成(R, G, B, s)，s表示的是顏色的scale肥败，在解碼的時候只需要使用s * weight * (R, G, B)即可

根據(jù)端點表達(dá)所需要的數(shù)值數(shù)目不同趾浅，可以分為如下的四種情況，每種情況各對應(yīng)四種編碼模式[6]：

2-values
4-values
6-values
8-values

每種模式都有各自的編碼特點馒稍，比如部分模式在編碼的時候?qū)τ谝恍┩ǖ罆幸恍┨厥庹疹櫭笊冢瑸檫@些通道分配更多的位數(shù)等，具體細(xì)節(jié)請參考文獻(xiàn)[6]纽谒。

block壓縮示意圖

對于每個block中的像素证膨，會存儲其相對于端點的插值權(quán)重（weight），不過這里需要注意的是鼓黔，插值權(quán)重的數(shù)目跟block像素的數(shù)目可能不是一一對應(yīng)的央勒，尤其是對于一些比較大的block而言不见，存儲的權(quán)重是稀疏的，在使用前會需要對權(quán)重進(jìn)行一次插值订歪，計算出當(dāng)前像素的權(quán)重务热，之后再使用這個權(quán)重插值出對應(yīng)的color或者其他數(shù)據(jù)。

對于block中顏色分布比較復(fù)雜的情況掌实，ASTC還會先對block的顏色進(jìn)行分析矢否，將block拆分成多個sub-block（最多四個[3]，sub-block的數(shù)目會由一個2bits的區(qū)域指定眼虱，如果指定的sub-block數(shù)目超過1的話喻奥，那么就需要額外的10個bits用于指定劃分模式索引（partition pattern index），劃分模式索引用于描述每個像素對應(yīng)的sub-block的索引（參考下面的示意圖）捏悬，實際存儲的時候不會為每個像素分配兩個bits用于說明劃分模式索引撞蚕，每個劃分模式是通過hash函數(shù)生成的，其輸入是相應(yīng)像素的uv坐標(biāo)以及sub-block的索引）过牙，之后每個sub-block當(dāng)成一個block進(jìn)行處理甥厦，在解壓的時候會先定位當(dāng)前像素對應(yīng)的sub-block，之后在sub-block的基礎(chǔ)上進(jìn)行數(shù)據(jù)還原寇钉，這里需要注意的是每個sub-block都會保存自己獨立的端點數(shù)據(jù)（也有著自己的壓縮策略刀疙，比如某個sub-block支持LDR，而另一個則支持HDR等[6]扫倡，不過這種多樣性是有限制的谦秧，出于抑制不常用搭配從而減少用于描述color-mode的位數(shù)的考慮，這里限制相同block中的不同sub-block的color mode在斷點顏色數(shù)值數(shù)目差異不能超過4撵溃，比如只支持2-values與4-values疚鲤，4-values與6-values，不支持2-values到6-values等的搭配[6]）缘挑，但是其使用的權(quán)重數(shù)據(jù)在各個sub-block中是共享的[3]（共享權(quán)重有什么意義集歇？）。

sub-block壓縮

對于一些各通道數(shù)據(jù)關(guān)聯(lián)性比較差的情況（比如RGBA分別存儲的是完全不同的四張貼圖）语淘，ASTC還支持為每個通道分配一套完全不同的權(quán)重（端點數(shù)據(jù)本身就是不同的诲宇，無需額外處理），這樣可以保證不同通道的插值結(jié)果側(cè)重點不一樣[3]亏娜。

block中的數(shù)據(jù)存儲采用的是Bounded Integer Sequence Encoding（BISE）的方式進(jìn)行的焕窝，以盡可能的節(jié)省存儲空間，而這就是ASTC算法的核心[1]：

對于一個block中包含5個權(quán)重值维贺，比如0, 0.25, 0.5, 0.75, 1.0它掂，我們可以用整數(shù)0~4來表示從而壓縮權(quán)重的浮點存儲空間。
對于每個整數(shù)，按照傳統(tǒng)方法虐秋，需要分配3個bits榕茧，但是會有三個數(shù)值是浪費的(5, 6, 7)，對于不同的最大值客给，浪費的幅度也不同用押，具體參考下圖，只有5個數(shù)值是有效的靶剑，而對于三個這樣的group（難道每個group都是0~4蜻拨？需要額外的映射表，見下面的映射表部分）桩引，可能就是5^3 = 125個有效數(shù)值缎讼，這個比較接近2^7 = 128，因此如果我們有辦法將這三個group合并到一起進(jìn)行編碼坑匠，就能很好的解決3個數(shù)值的浪費問題血崭，這樣原來3個group中每個像素3個bits，三個像素9個bits就可以直接使用7個bits來代替了厘灼，這個以5位基數(shù)的編碼（為什么要以5為基數(shù)夹纫？如果建立一個映射表的話，15個數(shù)值只需要4個bits就可以了吧璋肌舰讹？因為這個映射表是全局的，包含了0~124的所有可能數(shù)值）模式稱之為基于5的BISE壓縮围来；

浪費的空間尺寸與最大整數(shù)關(guān)系

映射表[2]：map_quints_to_integer[0][4][3] = 23
map_quints_to_integer[5][5][5] = {
{
{0, 1, 2, 3, 4,},
{5, 6, 7, 8, 9,},
{10, 11, 12, 13, 14,},
{15, 16, 17, 18, 19,},
{20, 21, 22, 23, 24,},
},
...
... // Skipped some portion
...
{
{101, 102, 103, 104, 105},
{106, 107, 108, 109, 110},
{111, 112, 113, 114, 115},
{116, 117, 118, 119, 120},
{121, 122, 123, 124, 125},
},
};
同理跺涤，對于每個group包含3個數(shù)值的情況而言匈睁，就可以用基于3的BISE壓縮监透，將5個group放到一起進(jìn)行編碼，每個group一個像素只需要8個bits<2*5 = 10bits航唆。
對于group的候選數(shù)值不是3胀蛮，也不是5的時候雖然也可以按照BISE的方式進(jìn)行編碼，但是其浪費的幅度可能稍微多一點糯钙。
BISE可以將整數(shù)編碼分別拆分成如下三種情況：

如果N <= 2^n - 1（0粪狼，1，3任岸，7再榄，15，31...）享潜，N-1二進(jìn)制的最高3位為11x困鸥，因為這種情況下N已經(jīng)接近于2^n，可以直接使用n個bits來對整數(shù)進(jìn)行編碼，S個整數(shù)只需要S*n bits就可以存儲

如果N <= 3 * 2^n - 1（ 2疾就，5澜术，11，23猬腰，47鸟废，95...），N-1二進(jìn)制的最高3位為101姑荷，將前面2個bits抽出來（取值范圍0~2盒延，不可能出現(xiàn)11的情況）使用前面基于3的BISE編碼（即對于2^n 前的系數(shù)使用一個trit編碼，5個group共同編碼鼠冕，每個數(shù)值占用8/5bits）兰英，剩下的部分按照2^n編碼，使用nS + ceiling(8S/5) bits就可以存儲

如果N <= 5 * 2^n - 1（4供鸠，9畦贸，19，39楞捂，79薄坏，159...），N-1二進(jìn)制的最高3位為100寨闹，將前面3個bits抽出來（取值范圍0~4）使用前面基于5的BISE編碼（即對于2^n 前的系數(shù)使用一個quint編碼胶坠，3個group共同編碼，每個數(shù)值占用7/3bits）繁堡，剩下的部分按照2^n編碼沈善，使用nS + ceiling(7S/3) bits就可以存儲

舉個例子，假如N=12椭蹄，N-1的最高三位為101闻牡，因此可以用一個trit（公式中的t表示的是最高兩位）以及兩個bits來表示，用公式來描述绳矩，就是 $X=t2^2+b_12^1+b_02^0$
如果N=40罩润，N-1最高三位為100，因此可以表示成3個bits+一個quint（公式中的q翼馆，表示的最高三位）： $X = q2^3+b_22^2+b_12^1+b_02^0$
經(jīng)過BISE編碼之后的空間浪費與編碼之前的空間浪費比較見下圖：

BISE優(yōu)化

下面給出ASTC壓縮格式使用時的一些建議[5]：

由于ASTC提供了眾多不同的壓縮模式割以，每個壓縮模式的壓縮率都各不相同，雖然使用起來比較靈活应媚，但是在把控上可能會需要花點心思严沥，這里為了方便說明，列出此前其他壓縮方法的一些基本特征中姜，用于與ASTC壓縮模式進(jìn)行比對：

其他壓縮模式

上圖中顏色格式中帶有+號的消玄，指的是貼圖中存了兩塊無關(guān)數(shù)據(jù)的情況，比如RGB+A，表示A通道與RGB通道的數(shù)據(jù)完全無關(guān)聯(lián)莱找，這種模式下酬姆，當(dāng)A通道數(shù)據(jù)與RGB通道數(shù)據(jù)無關(guān)時，能夠得到很好的壓縮質(zhì)量奥溺，但是當(dāng)他們本身是關(guān)聯(lián)時辞色，按照這種模式壓縮得到的質(zhì)量就比不過完全當(dāng)成關(guān)聯(lián)數(shù)據(jù)來壓縮質(zhì)量好。

由于ASTC解壓后的數(shù)據(jù)肯定會被用于填滿四個通道的浮定，因此對于那些原始貼圖中占用的通道小于4個的情況要怎么處理會比較困惑相满，實際上壓縮后的數(shù)據(jù)是可以根據(jù)需要只占用1個或者多個通道的（每個block可以單獨設(shè)置），而性價比最高的方案就是在保證質(zhì)量的前提下盡量少的占用壓縮后的數(shù)據(jù)通道桦卒，這里有兩個特例需要說明：

ASTC提供了一種將RGB通道編碼成一個luminance數(shù)據(jù)的方法立美，因此只需要占用一個通道即可
ASTC提供了一個將alpha默認(rèn)看成1.0的壓縮方法，在特定的情況下方灾，就可以省掉alpha通道的空間占用
在使用的時候建蹄，建議根據(jù)輸入貼圖的格式來調(diào)整壓縮的方案。

壓縮方案

根據(jù)上面的兩個特例裕偿，上圖給出了四種建議的壓縮方法洞慎，分別對應(yīng)RGB是否要用單個luminance進(jìn)行存儲以及alpha是否可以用1.0替代等四種情況。coding swizzle指的是壓縮編碼時數(shù)據(jù)的存放布局嘿棘，比如L+1情況下rrr1表示的是將luminance存儲到r通道（RGB壓縮成一個通道）劲腿，alpha不占用額外空間；sampling swizzle指的是貼圖采樣的時候建議的使用方式鸟妙，之所以使用.g而不使用.r是因為考慮到與其他的壓縮格式比如BC1/ETC等的兼容焦人，避免不同的壓縮格式下，需要兩套不同的shader代碼重父，并不是因為g通道有什么特殊的能力花椭，同樣.ga也是一樣的道理。

有了前面的鋪墊坪郭，我們就可以參考下面這張圖來對比其他壓縮模式與ASTC壓縮模式了：

ASTC與其他壓縮模式比對

此外个从，這里還有兩點需要注意：

關(guān)于sRGB脉幢，由于sRGB可以存儲更多人眼所需要的信息歪沃，因此對于顏色等數(shù)據(jù)，盡量使用sRGB進(jìn)行壓縮嫌松，不過需要注意的是沪曙，sRGB只針對RGB三通道，對于alpha通道而言萎羔，還是采用線性編碼存儲的
關(guān)于HDR液走，ASTC對于HDR格式的貼圖有兩種壓縮模式，第一種是將RGB看成是HDR（超出[0.0, 1.0]范圍）的，但是Alpha還是LDR的缘眶；第二種則是將RGBA四個通道都看成是HDR的嘱根，各位在實際使用中可以根據(jù)實際情況進(jìn)行選擇。

質(zhì)量對比

先看看壓縮后的貼圖與原貼圖的方差對比：

BaseColor

pvrtc/etc2的壓縮質(zhì)量介于astc 8×8和astc 10×8之間巷懈。

Normalmap

pvrtc壓縮質(zhì)量介于astc 6×6和astc 8×5之間该抒。 etc2壓縮質(zhì)量介于astc 8×8和astc 10×8之間。

帶alpha貼圖（lightmap）

pvrtc壓縮質(zhì)量介于astc 8×8和astc 10×8之間顶燕。 etc2壓縮質(zhì)量介于astc 5×4和astc 6×5之間凑保。

參考文獻(xiàn)

[1]. ARM Unveils Details of ASTC Texture Compression at HPG Conference
[2]. FLEXIBLE TEXTURE COMPRESSION USING BOUNDED INTEGER SEQUENCE ENCODING
[3].High quality RGBM texture compression with ASTC
[4]. Adaptive Scalable Texture Compression
[5]. Effective ASTC Encoding
[6].Adaptive Scalable Texture Compression