2. RAW数据解析：Bayer阵列、CFA原理与内存存储
好，咱们直接进入正题。RAW格式之所以叫“RAW”，就是因为它最原始——传感器捕捉到的电荷信号，几乎没经过任何加工。想用好它，你得先搞懂三件事：Bayer阵列怎么排的、CFA到底在干什么、以及这些数据在内存里到底长什么样。
我个人习惯把这三件事合在一起理解，因为它们本质上是一体的。你想想看，传感器本身是色盲的，它只能感知光的强度，分不清红绿蓝。那怎么拍出彩色照片？靠的就是CFA——彩色滤波阵列。而Bayer阵列，就是CFA里最常见的一种排列方式。
2.1 Bayer阵列模式
Bayer阵列是1976年由柯达的Bryce Bayer发明的。它的核心思想很简单：每个像素只记录一种颜色，然后通过插值算法猜出另外两种颜色。
最常见的Bayer模式是RGGB，也就是一个2x2的单元里，有1个红色像素、2个绿色像素、1个蓝色像素。为什么绿色多一倍？因为人眼对绿色最敏感，多采样绿色能提升视觉分辨率。
| 像素位置 | 颜色 | 占比 | 说明 |
|---|---|---|---|
| (0,0) | R | 25% | 红色像素 |
| (0,1) | G | 25% | 绿色像素（第一行） |
| (1,0) | G | 25% | 绿色像素（第二行） |
| (1,1) | B | 25% | 蓝色像素 |
嗯，这里要注意：Bayer阵列不是只有RGGB这一种。还有RCCC（用于安防监控）、RCCB（用于低光照）、甚至四拜耳阵列（Quad Bayer，用于高像素手机）。但不管怎么变，核心逻辑是一样的——每个像素只采样一种颜色。
关键点：Bayer阵列的排列决定了后续去马赛克（Demosaic）算法的复杂度。我曾经在项目中遇到过客户用非标准Bayer排列的传感器，结果标准插值算法直接崩了，颜色全错。后来我手动改了插值权重才搞定。
2.2 CFA（彩色滤波阵列）原理
CFA就是贴在传感器像素阵列上的一层微型滤光片。每个滤光片只允许特定波长的光通过。说白了，它就是一个光学带通滤波器。
CFA的设计有几个关键参数：
- 光谱响应曲线：每个颜色通道的透光率随波长变化的曲线。好的CFA，R/G/B通道的响应曲线重叠少，颜色分离度高。
- 量子效率：传感器把光子转换成电子的效率。CFA会吸收一部分光，所以加了CFA后，整体量子效率会下降。
- 串扰（Crosstalk）：相邻像素的滤光片之间会有光泄漏。比如红色像素旁边漏了点蓝光，就会导致颜色不准。
我记得有一次调试一个工业相机，发现红色通道总是偏紫。查了半天，发现是CFA的红色滤光片和蓝色滤光片的响应曲线在近红外波段有重叠。后来加了红外截止滤镜才解决。
避坑指南：我曾经在选型时只看传感器分辨率，忽略了CFA的光谱特性。结果在荧光成像场景下，绿色通道和红色通道严重串扰，后期怎么调都救不回来。选传感器时，一定要看CFA的光谱响应曲线，尤其是你的应用场景有特殊光谱需求时。
2.3 RAW数据在内存中的存储结构
搞清楚了Bayer和CFA，咱们来看看RAW数据在内存里到底怎么存的。这直接关系到你怎么读数据、怎么处理、怎么优化性能。
RAW数据在内存中的存储方式，主要取决于三个因素：
- 位深（Bit Depth）：每个像素用多少位表示。常见的有10bit、12bit、14bit、16bit。位深越大，动态范围越宽，但数据量也越大。
- 像素排列顺序：Bayer阵列的扫描顺序。常见的有：
- 逐行顺序（Row-major）：按行从左到右、从上到下排列。最常用。
- 交错模式（Interleaved）：某些高速传感器会采用，但少见。
- 字节对齐（Byte Alignment）：比如12bit数据，是每个像素占2字节（浪费4bit），还是打包成3字节存2个像素？这会影响内存带宽和访问效率。
下面是一个典型的12bit RAW数据在内存中的存储示例（逐行顺序，每个像素占2字节）：
// 假设传感器输出为：R G R G ...
// G B G B ...
// 内存地址从低到高：
// 地址0: R像素 (12bit) + 4bit填充
// 地址2: G像素 (12bit) + 4bit填充
// 地址4: R像素 (12bit) + 4bit填充
// 地址6: G像素 (12bit) + 4bit填充
// 地址8: G像素 (12bit) + 4bit填充
// 地址10: B像素 (12bit) + 4bit填充
// ... 以此类推
// 用C语言读取一个像素的示例：
uint16_t raw_data[width * height]; // 每个元素16bit，实际只用了低12bit
uint16_t pixel_value = raw_data[row * width + col] & 0x0FFF; // 取低12位
警告：不同厂商的RAW数据存储格式可能完全不同。索尼、三星、安森美都有自己的字节序和打包方式。我曾经因为没仔细看数据手册，直接按标准Bayer顺序读数据，结果图像全是条纹。后来发现厂商把Bayer阵列旋转了90度。所以，拿到RAW数据后，第一件事就是确认数据手册里的存储格式。
2.4 知识结构图：RAW数据解析全景
下面这张图把Bayer阵列、CFA原理、内存存储结构串在了一起。你可以把它当作本章的知识地图。
2.5 不同位深与存储格式对比
实际项目中，你可能会遇到各种位深和存储格式。下面这个表格是我整理的常见组合，方便你快速对照。
| 位深 | 每像素字节数 | 常见打包方式 | 典型应用 |
|---|---|---|---|
| 8bit | 1 | 直接存储 | 低端摄像头、预览流 |
| 10bit | 2（浪费6bit）或打包 | 5像素占8字节（5×10=50bit→6.25字节，对齐到8字节） | 手机ISP、视频编码 |
| 12bit | 2（浪费4bit）或打包 | 2像素占3字节（2×12=24bit→3字节） | 专业相机、工业检测 |
| 14bit | 2（浪费2bit） | 4像素占7字节（4×14=56bit→7字节） | 高端单反、科学成像 |
| 16bit | 2 | 直接存储 | 天文、医疗、科研 |
个人经验：我建议在算法原型阶段，先把所有RAW数据统一转成16bit无符号整型（uint16_t）再处理。虽然浪费一点内存，但能避免各种位深和打包方式带来的边界问题。等算法稳定了，再针对特定格式做优化。
2.6 本章小结
好，咱们捋一下。Bayer阵列决定了每个像素采样什么颜色，CFA决定了这些颜色的光谱质量，而内存存储结构决定了你怎么把这些数据读出来用。这三者环环相扣，任何一个环节出问题，后面的处理都会跟着跑偏。
嗯，我记得刚入行时，总觉得RAW解析就是读像素值，没什么技术含量。直到有一次，因为没搞清楚传感器的Bayer排列顺序，导致整个去马赛克算法输出全是马赛克——嗯，字面意义上的马赛克。从那以后，我再也不敢跳过数据解析这一步了。