ETC1压缩算法详解

美女

ETCPACK

ETC 压缩算法的基本思想
将图片分成 4x4 的若干个像素块，每个像素块按照一定规则编码成为一个 64 位(8字节)的数据，大概的想法是计算像素块的平均颜色，然后记录这个平均颜色和每个像素相对平均颜色的差值，平均颜色只耗费了一个像素的数据，而差值也并不记录完全真实的差值，而是从一个固定的静态数据中找到最接近的差值（RGB三个通道差值一样），每个像素只需要记录其差值在静态数据中的索引即可。
压缩比
对于 RGB24 图片，每个块的数据由 4x4x3 = 48字节，压缩为 8字节，压缩比为 6:1，针对Alpha图片，由4x4x1 = 16字节压缩为 8 字节，所以，对于普通的 RGBA 分离为 RGB24 和 Alpha 之后分别进行 ETC1 压缩的图片，整体压缩比为 (48 + 16) : (8 + 8) = 4:1
文件头数据
除了编码后的数据块之外，还会存储一部分文件头数据，用来表示文件的特征码、宽高等

如何将一个 4x4 的像素块编码为 64 位数据呢?

将 4x4 的像素块分为两个 4x2 的子块，有水平和竖直两种分法。使用 1位数据flipbit来表示是哪一种分法，还剩下 63 位数据

flipbit表示子块分法

分别计算两个分块中 8 个像素颜色的平均值，根据两个块颜色平均值的差值，确定使用 individual模式还是 differential 模式。使用 1位数据diffbit来表示是哪种模式，还剩下 62位数据
存放两个子块的平均颜色信息，individual模式用R4G4B4 的格式分别表示两个子块的平均颜色，differential 模式使用 R5G5B5 格式表示第一个子块的平均颜色，R3G3B3 格式表示第二个子块与第一个子块平均颜色的差值。这里使用了 8 * 3 = 24 位数据，还剩下 62-24 = 38 位数据

可以这么理解:当两个子块的平均颜色值相差比较小时，基本颜色可以使用更高精度的 R5G5B5 来替代R4G4B4获得更少的信息损失

所有的图片共享一个全局的映射表数据，这个数据是固定的全局静态数据，并不会进入到编码数据中，这个表是一个 8 x 4 的二维数组，使用 3 位数表示第一个子块在映射表中查询的第一维索引，需要3位来表示 0-7 的下标，第二个子块同样需要 3 位数来表示，还剩下 38-3*2 = 32位数据
4x4像素块中的每个像素，使用2位数来表示该像素在映射表中查询的第二维索引，需要2位数来表示0-3的下标，所以消耗了 4x4x2 = 32 位数据

以上就是编码后的 64 位数据块表示的意义

以RGB555基本色和RGB3333颜色差表示的编码为例，每个4x4 像素块经过ETC1 编码后的 64 位数据的内存布局大概是这样

ETC1内存布局

假如编码前像素块表示为下图

目标像素

我们需要得到图中编号2对应像素的颜色，需要进行如下的解码步骤：

获取目标所在的子块
根据第32位 flipbit 标志位，知道这个像素块采用的是横版划分子块，2号像素处在子块2中
获取子块1基本颜色
首先根据第 33 位 diffbit 标志位得知，这里采用的是 R5G5B5 基本色 + R3G3B3 差值的方式。分别从59-63位(11100)、51-55位(00100)和43-47位(00011)读取子块1基本色 RGB1=(11100, 00100, 00011) = (28, 4, 3)
获取子块2的颜色差值
这里是 differential 模式，所以需要读取子块2的颜色差值，从56-58位(100)、48-50位(010)和40-42位(000)获得颜色差值 RGB_offset=(100, 010, 000) = (-4, 2, 0)，注意这里的3位数据中最高位是符号位，所以差值部分的取值范围是[-4, 3]
计算子块2的基本色
将子块1基本色和子块2差值相加，得到子块2的基本色，RGB2=RGB1 + RGB_offset = (28 - 4, 4+2, 3+0) = (24, 6, 3)，转为5位二进制表示为 RGB2=(11000, 00110, 00011)
扩展子块2基本色分量为8位
对5位标识的基本色补位为8位表示，得到 RGB1 = (11000110, 00110110, 00011011) = (198, 54, 27)，这就是子块2的基本色

补位规则:

individual 模式，直接将4位数复制到尾部，得到8位
differential 模式，将5位中的高3位复制到尾部，得到8位
differential 模式，一定是将子块1基本色和子块2偏移值相加后再进行补位

获得目标像素的颜色偏移值
目标像素下标为2，在编码数据的第2位得到映射表的下标的低位(lsb)为1，第18 位得到映射表的下标高位(msb)为1，假如使用如下的映射表，则可以得到映射表下标为(lsb, msb)=(1,1)，对应下标为 -b

映射表

这里的映射表是一个全局数据，不会编码到文件中。但是这个全局数据是怎么来的，放在什么地方，没有查到相关资料。不过因为解码时要用，所以我估计是存放在纹理的某个全局区域

上面知道目标像素位于子块2，这里还需要从编码数据的34-36获得子块2的修正表索引，得到索引为(1,1,0)=6，根据上面的映射表，根据下标(6, -b) 可以索引到像素的颜色差值为-106

计算目标像素的最终颜色值
这里RGB三个分量的差值相同，目标像素最终的颜色值为子块2的基本颜色 + 目标像素的颜色偏移值：
RGB_target = RGB2 + (-106, -106, -106) = (198 - 106, 54 - 106, 27 - 106)，修正后得到目标颜色值 RGB_target = (92, 204, 177)

其实从上面的解压过程可以推测出编码的过程

映射表里的数据是怎么确定的？映射表数据存放在哪里？
取子块平均色时，原本R8G8B8的数据是怎么压缩成R5G5B5的？
是直接抛弃后三位吗?
还是按照比例来压缩？比如 8 位时 11111111 表示 256，5位时 111111（实际值是31）表示256，原本8位时的值 x，则5位时的y值，y= x * (31/256) 取整得到的5位二进制表示？从解码的补位过程看起来应该是直接抛弃掉后三位。后三位的数据其实就损失了。

参考：
UI图集压缩优化，以及对Dither和ETC1算法的深入了解
几种主流贴图压缩算法的实现原理详解
OES_compressed_ETC1_RGB8_texture