从Sensor到屏幕：YUV、RGB与RAW DATA格式的选型实战与性能权衡

1. 图像传感器输出格式的三大门派

第一次接触摄像头开发时，我被各种数据格式搞得晕头转向。YUV、RGB、RAW DATA就像三个性格迥异的朋友，各有各的做事方式。简单来说，YUV像是精明的会计，懂得压缩数据节省空间；RGB像直爽的画家，原汁原味呈现色彩；RAW DATA则像未经雕琢的原材料，保留全部原始信息但需要后期加工。

在实际项目中，我遇到过因为选错格式导致系统卡顿的尴尬情况。比如用RGB565处理1080P视频时，画面直接变成幻灯片。后来改用YUV420，同样的硬件却能流畅播放。这让我深刻体会到，格式选型不是纸上谈兵，而是直接影响系统性能的关键决策。

三种格式最直观的区别在数据量上。以1080P图像（1920x1080）为例：

• RGB888：1920x1080x3 ≈ 6MB
• YUV420：1920x1080x1.5 ≈ 3MB
• RAW10：1920x1080x1.25 ≈ 2.5MB

数据量差异直接影响传输带宽和处理功耗。去年做智能门铃项目时，就因为从RGB切换到YUV，电池续航直接提升了30%。这还只是冰山一角，接下来我们深入看看每种格式的"内功心法"。

2. RAW DATA：最原始的图像真相

2.1 从光子到数字的旅程

当光线穿过镜头落在传感器上时，发生的第一个魔法就是RAW DATA的诞生。每个像素点就像个微型光桶，只收集特定颜色的光子。由于拜耳滤镜的排列，RAW数据本质上是单通道的——每个像素只有R、G或B中的一个值，其他两个颜色需要靠猜（其实就是插值算法）。

我在调试OV4686传感器时，发现它的RAW10格式特别有意思：

// 典型RAW10数据包结构 struct raw10_packet { uint8_t pixel0_high : 6; // 高6位 uint8_t pixel1_high : 6; uint8_t pixel2_high : 6; uint8_t pixel3_high : 6; uint8_t low_bits; // 4个像素的低4位(每个像素占2bit) };

这种打包方式既节省带宽又保留更多暗部细节，比RAW8更适合低光环境。不过要小心，不同厂家的RAW格式可能像方言一样存在差异，海思ISP和安霸DSP对RAW的解析配置就完全不同。

2.2 ISP的炼金术

RAW数据必须经过ISP（图像信号处理器）的"点化"才能变成可用图像。这个过程就像把生米煮成熟饭：

1. 坏点校正：修复传感器上的"偷懒"像素
2. 黑电平补偿：消除电路固有噪声
3. 去马赛克：通过插值算法重建全彩图像
4. 色彩校正：调整白平衡和色彩矩阵

在RK3588平台上调试时，我记录过ISP处理延时：

RAW格式的优势在于后期处理自由度。有次客户抱怨夜间画面偏绿，我们通过调整ISP的3D降噪参数就解决了，如果是YUV格式就无力回天了。但代价是需要强大的ISP支持，低端芯片可能扛不住5MP以上的RAW数据流。

3. RGB：直来直去的色彩表达

3.1 格式变种与适用场景

RGB格式就像调色盘，通过红绿蓝三原色的混合来表达所有颜色。但在嵌入式领域，我们常用的是它的精简版：

• RGB565：16位格式，R5G6B5分配
• RGB888：24位真彩色
• ARGB8888：带alpha通道的32位格式

在STM32F429的LTDC接口上，我实测过不同格式的刷新率：

RGB565特别适合直接驱动显示屏，因为大多数MCU屏控制器都原生支持。但要注意人眼对绿色更敏感，所以G通道多1bit不是没有道理的。曾经有个项目为了省内存用RGB555，结果画面看起来就像蒙了层灰雾。

3.2 内存布局的坑

RGB数据在内存中的排列方式可能让你踩坑。比如在OpenCV中：

// 常见错误：忘记考虑stride对齐 cv::Mat rgb_image(height, width, CV_8UC3, frame_buffer);

有些硬件会要求每行数据64字节对齐，这时width=127会比width=128反而更耗内存。我有个血泪教训：在Allwinner V3s上，没设置正确的framebuffer stride导致画面出现锯齿状扭曲。

另一个冷知识是字节序问题。Big-endian的ARGB在Little-endian系统上会显示成BGRA。有次调试Android摄像头预览，画面颜色完全错乱，最后发现是：

// 必须与HAL层格式一致 imageReader = ImageReader.newInstance( width, height, ImageFormat.RGB_565, 2);

4. YUV：平衡的艺术大师

4.1 采样格式的智慧

YUV的聪明之处在于它知道人眼更关注亮度而非颜色。YUV4:2:0就像个压缩高手，把色度信息压缩到原来的1/4，但人眼几乎察觉不到差异。这是我在不同场景下的实测码率对比：

YUV420在视频场景性价比最高，但在需要OCR识别的场景，我会建议用YUV422甚至YUV444，因为文字边缘的色度信息很重要。

4.2 内存布局的七十二变

YUV的存储格式复杂得让人头疼，光是planar和packed就够喝一壶。在V4L2驱动开发时，我整理过常见格式的配置方法：

// 设置视频采集格式 struct v4l2_format fmt = { .type = V4L2_BUF_TYPE_VIDEO_CAPTURE, .fmt.pix = { .pixelformat = V4L2_PIX_FMT_NV21, // Android常用 .width = 1920, .height = 1080, .field = V4L2_FIELD_NONE, } }; ioctl(fd, VIDIOC_S_FMT, &fmt);

特别提醒：NV21和I420的内存占用相同，但访问模式会影响性能。在麒麟980上测试发现，连续访问Y分量时，I420比NV21快15%，因为Y数据是连续的。

5. 实战选型指南

5.1 硬件能力匹配

选格式就像给汽车选燃油，不是标号越高越好。以下是常见芯片的处理能力参考：

有个取巧的方法：查看芯片的VIPP（Video Input Pre-Processor）模块支持列表。比如TI的DM8127就明确写着：

VIPP0: YUV422SP -> RGB888转换耗时2ms VIPP1: RAW10 -> YUV420转换耗时5ms

5.2 场景驱动的决策树

我总结了个简单的决策流程：

1. 需要后期调色？→ 选RAW
2. 直接显示且资源有限？→ RGB565
3. 视频编码或网络传输？→ YUV420
4. 文字识别需求？→ 考虑YUV422
5. 高端AI视觉？→ RAW+YUV双路输出

在智能家居项目中，我们甚至动态切换格式：待机时用低分辨率YUV省电，触发报警后立即切换高分辨率RAW抓细节。

5.3 性能优化技巧

• 带宽优化：使用CSC（Color Space Conversion）硬件模块，海思3559A的CSC单元能把YUV转RGB的功耗降低80%
• 内存优化：对于YUV420，分配内存时按32字节对齐能提升DMA效率
• 延时优化：瑞芯微RKNN支持YUV直接输入神经网络，省去转换步骤

最后分享一个真实案例：车载DMS系统最初采用RGB888，后来改为YUV420+局部RAW的方案，既满足人脸识别精度，又把系统功耗从12W降到了7W。这告诉我们，混合使用不同格式往往是最优解。