ios - 垂直翻转 PVRTC 压缩图像数据

Question

我有一些 PVRTC 4bpp 图像数据需要在不解压缩的情况下就地垂直翻转。我编写的代码大部分都可以正常工作，但翻转目前引入了小的人工制品，我不确定到底是为什么。

PVRTC 翻转代码首先将 8 字节 4x4 压缩 block 移动到由 PowerVR SDK 中 PVRTDecompress.cpp 的 TwiddleUV() 函数计算出的翻转位置。这部分似乎是正确的。

其次，代码遍历所有 8 字节压缩 block ，反转包含存储在 2bpp 中的 4x4 调制数据的第二个 4 字节的顺序。 block 的前 4 个字节包含保持不变的颜色数据。

这似乎非常接近正确，但它在翻转后的图像中留下了原始图像中不存在的小瑕疵，主要表现为小的灰色水平线。如果翻转代码运行两次，则伪影消失，图像与原始图像保持不变。

有 PVRTC 经验的人能解释一下翻转压缩图像数据还需要做什么吗？我认为问题可能与调制数据的翻转有关，但我对 PVRTC 文档的探索在这个阶段还没有找到答案。

Answer 1

为了更容易理解，您需要了解 PVRTC 解码数据的方式，因为它与 ETC1 或 S3TC/DXTC 等基于 block 的方案有点不同。为简单起见，我将只描述 4bpp 变体。

PVRTC 由 2 个低分辨率 15/16bpp 图像 A 和 B 组成，它们是最终纹理分辨率的 1/4 * 1/4，以及一个全分辨率但 2bpp 调制图像。为了“逻辑上”解码纹素 XY，A 和 B 图像被双线性放大到目标分辨率，然后根据调制图像中的像素混合生成的颜色 Axy 和 Bxy。为了使硬件解码更简单，A 和 B 图像与调制数据以 1 个像素的速率与来自调制数据的 16 个像素交织成 64 位字。

现在，它不能仅使用位改组进行精确翻转的原因是因为 4x4 双线性放大与 4x4 纹素的中心略有偏移(我认为原因在 Graphics Hardware 2003 论文 linked from wikipedia 中有所描述)。我希望你唯一能做的就是实际评估每个像素，然后在翻转双线性颜色之后，找出四种可能性中哪一种实际上最接近。在某种程度上，这将是一次重新压缩，但应该相对较快。