GPU 实现 RGB -- YUV 转换 (OpenGL)

GPU 实现 RGB -- YUV 转换

前言

RGB --> YUV 转换的公式是现成的，直接在 CPU 端转换的话，只需要遍历每个像素，得到新的 YUV 值，根据其内存分布规律，合理安排分布即可。然而在 CPU 端进行转换，存在的问题运行效率太低，无法满足高效转换的需求。我们将目光投向拥有流水线体系的支持高速浮点数计算的硬件——GPU.

转换公式如下：

GPU 上面的实现

考虑在 GPU 上执行 RGB --> YUV 转换。GPU 的流水线操作：

vertices
        ----> Pipeline ----> Out color
texture

所以将 RGB 图像作为纹理输入，流水线输出我们需要的 YUV 数据。前面一部分很好理解，图像作为唯一的纹理输入，没有别的选项。后面一部分的话，需要在输出的时候输出我们需要的 YUV 数据即可，在 fragment shader 中的输出按常理就是每一个 fragment 的颜色，为实现读取像素是 YUV 的目标，要调整输出的数据。

考虑 YUV 格式内存分布，以 NV12 为例，一张图片占用内存大小为：width x height * 3 / 2 (我们认为图像的宽为 width 高为 height). 如果是 RGBA 的格式存储的话，占用的内存空间大小是：width x height x 4 （因为 RGBA 一共4个通道）。如果我们把 OpenGL renderbuffer 大小设置成等于图像的大小，那输出的大小就是 RGBA 那一种的大小，和 YUV 格式的是对不上的。考虑 YUV 的分布特点，设计输出的宽高为 (width / 4, height * 3 / 2). 示意图如下：

Memory of a frame (yuv format)

  width / 4
|-------------|
|             |
|             | h
| chrominance |
|             |
|-------------|
|             |
| luminance   | h / 2
|-------------|

因为每一个 out color 含有四个分量 RGBA 所以将宽度设为 width / 4, 那么正好每一行的像素就是原来 width 的数量。在 fragment shader 内部计算的时候，需要考虑当前处理的单个 fragment 是属于 chrominance OR luminance, 可以用纹理坐标的 t 值的大小来判断。

Chrominance

所谓的 RGBA 四个分量实际上代表四个不同的像素的 chrominance 值，也就是说需要做一定的 offset, 来获取到当前像素附近的像素的值，我先假定 offset 为 1.0f / width. 故四个分量如下：

1. (s, t)
2. (s + off, t)
3. (s + off x 2.0f, t)
4. (s + off x 3.0f, t)

根据四个像素的 RGBA 值计算出四个 Y 通道的数据作为这个 fragment 的输出颜色。

Luminance

仍然是一个像素四个分量，但是现在代表的是两对 UV 分量。因为根据一个 RGBA 就可以算出 YUV 值，所以此处只需要做一个偏移。

1. (s, t)
2. (s + off x 2, t)

这里 offset 的设置可以乘 1 或 2 或 3，我觉得都可以，我只是取中道选择了 2. 将上面两个像素的 UV 分量作为这个 fragment 的输出颜色。

readback pixel

最终用 glReadpixels() 函数，将我们输出的颜色读回来，就完成了。

补充

实际操作中遇到的一个问题是，如果设置了 GL_BLEND, 最终输出的颜色会是混合以后的颜色，记得一定要确认关闭了 blending.

Written with StackEdit.