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.
严正声明：
作者：psklf
出处： https://www.cnblogs.com/psklf/p/8399726.html
欢迎转载，但未经作者同意，必须保留此段声明；必须在文章中给出原文连接；否则必究法律责任!