“先说结论：这不是巧合，而是工程权衡后的最优解。
它也不是"唯一解"——RAW10 撑不住 8M 前视的 HDR，RAW14 又要多花约 17% 带宽，RAW12 正好卡在"画质够用、带宽不亏"的甜点上。
熟悉自动驾驶摄像头的会发现一个很统一的现象：前视 8M 摄像头基本都是 RAW12 输出，而后视、环视却常常是 YUV。为什么唯独前视"要坚持用原始数据"？
要回答这个问题，得先搞清楚三件事：RAW 到底是什么？它和 YUV 差在哪？以及 RAW 后面那个数字为什么偏偏是 12？
RAW 和 YUV 不是同一类东西
这里说的"图像格式"不是我们手机里的 JPG、PNG，而是传感器到域控之间传输的数据格式。车载上常见的就两种：
RAW：CMOS 传感器直接吐出的原始数据，还没做任何处理。 YUV：RAW 经过 ISP 处理、去马赛克、转成亮度和色度分离之后的数据，可以直接给人看，也可以直接喂算法。
一句话记住区别：RAW 是"生米"，YUV 是"煮好的饭"。
RAW 是一张带马赛克的灰度图
CMOS 本身是"色盲"的——它只感知光的强弱，不认颜色。1979 年 Bryce Bayer 发明了拜耳阵列（Bayer Pattern）：在每个感光单元上分别盖上红、绿、蓝的微型滤光片，让每个像素只拿到一个颜色通道的信息，再靠相邻像素的插值还原色彩。今天的彩色相机，几乎都还在这套原理上工作。
除了最常见的 RGGB，还有 BGGR、GRBG、GBRG 等排布方式，只是滤镜的落位不同，本质一样。
RGGB 描述的是"滤光片怎么排"，RAW 记录的是"光穿过滤光片后的值"。 RAW 里其实就交织着 R/G/B 三个通道的采样，只是每格只有其中一个——所以肉眼看它就是一张带马赛克的灰度图。
从光子到 RAW，完整链条是这 6 步：
RAW 后面的数字，是位深
RAW8 / RAW10 / RAW12 / RAW14 / RAW16 的区别，本质是每个像素用几个 bit 来量化：
| 8M 前视主流 | |||
位深越大，量化越细、暗部越好恢复，但需要的带宽也越大：
YUV 是ISP 的"成品饭"
RAW 是马赛克数据，算法没法直接用，必须先过 ISP。YUV 就是 ISP 的输出：Y 是亮度（只看 Y 就是一张黑白照片），U/V 是去掉亮度后的蓝色、红色色度残差。
按色度采样密度分 YUV444 / 422 / 420，车载最常见的是 YUV422——水平方向每 2 个像素共用一组 U/V，带宽直接砍掉 1/3，对人眼几乎无感。
ISP 内部大致是这样一条流水线：黑电平 → 坏点 → 镜头阴影 → 去马赛克 → 白平衡 → 颜色校正 → Gamma → 色调映射 → 降噪 → 锐化 → 色彩空间转换 → YUV 输出，旁边还有 AE/AWB/AF 三个闭环在实时调节。
一般前视用 RAW，环视用 YUV？
实际上自动驾驶两种都在用，只是分工不同。判断标准只有一条：
这份数据最终给谁消费——给感知算法吃的走 RAW，给人眼 / 显示看的走 YUV。
为什么这个判断这么关键？因为 RAW 里保留了三样 YUV 拿不回来的东西：
Bayer 全采样：每个像素的原始感光值都在，去马赛克可以在域控上做得更聪明； HDR 合成前的完整动态范围：多曝光帧的融合策略由域控决定，而不是被 sensor 内置 ISP 焊死； 真实噪声特性：噪声有规律可循，域控上更先进的降噪算法才有发挥空间。
反过来，sensor 端的 ISP 一旦把降噪、色调映射、去马赛克"做死"，暗部细节和高光层次就被提前抹掉了——算法再强也恢复不了已经丢失的信息。
另外，RAW 进 SoC 之后，AE/AWB/AF 可以结合感知结果做闭环（比如按车道线区域的亮度做分区曝光），这也是前置 ISP 给不了的自由度。
那环视为什么用 YUV？因为环视主要拼环视视图、给人看、做近距离辅助，对"极限动态范围"要求没那么苛刻，而把它放在 sensor 端处理完，域控侧就省掉了 4~8 路 ISP 的算力和带宽压力——这是一个典型的成本优先选择。
为什么偏偏是 RAW12
从索尼 IMX728、豪威 OX08B40，到安森美 AR0820AT，再到思特威 SC360A/SC361A，主流 8M 前视的默认输出都是 RAW12，链路则是 GMSL2 / FPD-Link III + A-PHY 这一套。这是本文最重要的"事实底座"：不是某一家厂商的选择，而是整个行业的收敛结果。
目前常见的连接方式是两颗 8M 前视（双目）+ 一颗后视挂到同一个解串器上，更极致的成本方案还会把雷达等小数据量模组也塞进来，把链路带宽榨干。下文带宽计算统一以 IMX728（3840×2160@30fps）为基准。
RAW10 差在哪，RAW14 贵在哪
RAW 本身不能直接显示或推理，必须过 ISP。而 ISP 里几乎所有环节都是放大差异的：HDR 融合要把 3 帧曝光压进一个范围，色调映射要把 16bit 的动态范围压到 10bit 显示，局部对比度增强会拉伸梯度的两端。
RAW8：只有 256 级灰度，HDR 拉伸后必然出现色带、断层、伪轮廓。隧道出入口、逆光建筑、路面阴影过渡区，主观评价根本过不了——直接淘汰。 RAW10：大部分场景够用，但在 HDR 融合 + 色调映射之后，灰度台阶被"乘"了出来。对分割、车道线这类弱边缘目标，梯度信噪比下降，边缘会发虚、断裂。 RAW12：给 HDR 映射、局部对比度、去雾、色彩校正留了充足的量化裕度。隧道进出、夜间、逆光下灰度过渡平滑，肉眼看不到色带和伪轮廓。 RAW14：量化层级更足，理论效果最好，几乎不可能出色带
但在 RAW12 之后，肉眼已经很难分辨出差别了，直接看图感受一下：
这组图是按 RAW 位深量化后渲染的示意图，不是真实 sensor 的对拍，但足以体现趋势——RAW12 之后，肉眼基本就到顶了。所以 RAW12 覆盖了 90% 的场景，是最优解而不是唯一解。
多 2bit，链路就要多扛 17%
先算一颗模组的有效像素码率（只算有效像素，不含协议开销和消隐）：
W × H × f × b × η
W: 有效像素宽，单位 px，典型值 3840
H: 有效像素高，单位 px，典型值 2160
f: 帧率，单位 fps，典型值 30
b: 位深，单位 bit/px，典型值 12
η: 消隐系数（膨胀因子），典型值 1.2
精确值 = HTS×VTS/(W×H) = 1.215
代入 IMX728：
3840 × 2160 × 30 × 12 × 1.215 ≈ 3.63 Gbps ≈ 453.5 MB/s
换成 RAW14：3840 × 2160 × 30 × 14 × 1.215 ≈ 4.23 Gbps ≈ 529.1 MB/s，单颗多出约 75 MB/s，涨幅 16.7%。
这 17% 不是"多存点"那么简单，它决定了：
MIPI CSI 要配几根 lane、每 lane 最低跑多少速率； 同轴串行链路选 3G 档还是 6G 档（这一档之差直接是成本差）； SoC 要给 ISP 和 DDR 预留多少带宽； 同一颗解串器最多能挂几路模组。
而这 17% 换来的，是上面已经"肉眼看不出来"的那点画质。这笔账怎么算都不划算。
当然，速率从来不是决定格式的第一因素，RAW12 是"画质 × 带宽"两条曲线的交点：同样效果下带宽最小，同样带宽下效果最好。
RAW12 是被工具链"养"出来的
还有一个容易被忽略、但在量产里极其要命的因素——工具链。
从 Bringup 阶段的 sensor 调试上位机、RAW 帧抓取预览、协议分析仪抓包解析，到内核驱动、ISP 调参工具，再到离线 RAW 帧分析、产线镜头校正与颜色标定工装，以及后续的实车路采记录仪、HIL 仿真注入、自动化图像质量评测平台——每一环都需要对应格式的原生支持。
MIPI CSI、GMSL、V4L2、各家 ISP 调试工具，RAW12 都是"默认就支持"的那一档。严格说这是个正循环：因为 RAW12 是主流，所以工具都默认支持；也因为工具都默认支持，RAW12 才更稳地成为主流。 选一个非主流格式，等于自己给自己加一条产线排障的"孤岛路径"。
另外，RAW8/RAW12/RAW16 都能字节对齐，传输中的单 bit 错误只影响局部像素，可做行级屏蔽、插值修复，不会污染其他行的数据。RAW10/RAW14 需要打包，一旦出问题，错误会沿字节流"串行"扩散——这对功能安全（ASIL）诊断并不友好。
总结
RAW 格式的选型，从来不是单一维度的取舍，而是在带宽、传感器物理特性、ISP 硬件能力、MIPI 协议生态、显示主观效果、感知算法性能、HDR 融合鲁棒性、功能安全诊断、量产标定工具链、BSP 成熟度、功耗与误码容错构成的多维约束空间里，找一个可行解。
而 RAW12 之所以成为 8M 前视的"公约数"，是因为它同时满足：
够用：12bit 量化裕度足以扛住 HDR 融合和色调映射的放大效应； 不贵：比 RAW14 省 17% 带宽，让一颗解串器能挂更多路模组； 好落地：全链路工具、驱动、标定、评测都原生支持，量产风险最低。
一句话：RAW10 不够，RAW14 太贵，RAW12 刚刚好。
END
往期精选：
