ISP流水线整体架构：从RAW到YUV/RGB的旅程
各位同学，今天我们来聊聊ISP流水线的整体架构。说白了，就是搞清楚一张RAW图是怎么一步步变成我们眼睛看着舒服的YUV或RGB图像的。我做了这么多年ISP设计，每次看这条流水线，都觉得它像一条精密的数字食品加工线——生食材进去，熟美食出来。
核心观点：ISP流水线不是一条死板的固定链路，而是一个可配置、可裁剪的处理框架。不同传感器、不同场景、不同功耗预算，决定了你该走哪条路。
2.1 典型的ISP处理流程
先看一张我手绘的流程图。这张图我改过不下十版，现在这个版本是我觉得最清晰、最贴近硬件实现习惯的。
这张图里，我特意用蓝色和橙色把流水线分成了两段。左边蓝色是前端，右边橙色是后端。中间那条虚线，就是RAW域和RGB/YUV域的分界线。你想想看，前端处理的还是传感器直接出来的原始数据，后端才开始做颜色和视觉上的美化。
2.2 各模块功能概览
下面我把每个模块的核心功能列出来。这些模块我按处理顺序排了序，但实际项目中顺序是可以调整的。我记得有一次做安防摄像头方案，客户非要把去噪放在Demosaic之后，说效果更好。嗯，这就是工程——没有的对错，只有合不合适的场景。
| 模块 | 所属阶段 | 核心功能 | 我踩过的坑 |
|---|---|---|---|
| 黑电平校正 (BLC) | 前端 | 减去传感器暗电流偏移，恢复真实黑电平 | 曾经忘记做BLC，整张图偏紫，查了两天才发现 |
| 去噪 (Denoise) | 前端 | 去除传感器热噪声、读出噪声等 | 降噪强度调太高，人脸变成塑料质感 |
| 去马赛克 (Demosaic) | 前端 | 从Bayer阵列插值出完整RGB | 边缘伪彩色是常见问题，需要加方向判断 |
| 白平衡 (AWB) | 前端 | 校正色温偏差，让白色看起来是白的 | 室内暖光灯下经常偏黄，需要统计色温 |
| 自动曝光 (AE) | 前端 | 调整曝光时间和增益，控制亮度 | 逆光场景容易过曝，要加背光补偿 |
| Gamma校正 | 后端 | 非线性映射，适配显示设备特性 | Gamma曲线选错，暗部细节全丢 |
| 色彩校正 (CCM) | 后端 | 3x3矩阵变换，校正传感器色彩响应 | 矩阵系数精度不够，红色溢出严重 |
| 色调映射 (Tone) | 后端 | 压缩动态范围，保留亮暗部细节 | HDR映射做过头，画面像油画 |
| 锐化 (Sharp) | 后端 | 增强边缘对比度，提升清晰感 | 锐化太强，文字边缘出现白边 |
个人习惯：我一般把3A统计（AE/AWB/AF）放在前端，因为统计信息需要在RAW域就采集。后端再做一次精细统计，用于色彩和色调的微调。这样前后端各做一次，精度和实时性都能兼顾。
2.3 前端与后端划分
为什么要分前端和后端？说白了，这是硬件设计上的一个经典分水岭。
前端处理的是RAW数据，每个像素只有一种颜色分量（R/G/B之一）。这个阶段的数据量最大，但每个像素的信息量最小。我习惯把前端叫做"数据清洗阶段"——把传感器带来的各种脏数据洗干净。
后端处理的是RGB/YUV数据，每个像素都有完整的颜色信息。这个阶段的数据量虽然没变，但信息密度高了很多。后端我管它叫"美化阶段"——让图像看起来更讨人喜欢。
为什么会这样划分？我总结了几点实际原因：
- 带宽考虑：前端数据量大，但处理简单（加减乘除为主）。后端数据量不变，但处理复杂（矩阵乘、查找表、非线性映射）。分开了，硬件流水线才能跑得顺。
- 复用性：前端模块跟传感器强相关，换传感器就要调。后端模块跟显示/编码强相关，换显示器也要调。分开后，前端后端可以独立迭代。
- 调试便利：我在项目中遇到过，图像偏色了，先看前端还是后端？分开了，直接看分界点（Demosaic输出）的RAW图，就知道问题出在哪一段。
注意：前端和后端的划分不是的。有些ISP架构会把去噪放在Demosaic之后（后端），有些会把色调映射放在Gamma之前。我个人建议：先按标准架构做，再根据实际效果微调顺序。不要一开始就搞特殊化，容易翻车。
2.4 一个典型的处理实例
我拿一个200万像素（1920x1080）的传感器举例，看看数据在流水线里是怎么流的。
| 处理阶段 | 数据格式 | 数据量（每帧） | 典型延迟 |
|---|---|---|---|
| RAW输入 | Bayer RAW10 | 1920×1080×10bit ≈ 2.07MB | 0（传感器输出） |
| BLC + 去噪 | Bayer RAW10 | 2.07MB（不变） | 2~3行延迟 |
| Demosaic | RGB888 | 1920×1080×24bit ≈ 4.97MB | 5~7行延迟 |
| AWB + CCM | RGB888 | 4.97MB（不变） | 1~2行延迟 |
| Gamma + Tone | RGB888 | 4.97MB（不变） | 1~2行延迟 |
| 锐化 + 输出 | YUV420 | 1920×1080×12bit ≈ 2.48MB | 3~5行延迟 |
你看，数据量在Demosaic之后翻了一倍多。这就是为什么前端处理要尽量简单——数据量大，处理复杂了硬件吃不消。后端虽然处理复杂，但数据量已经稳定了，可以慢慢做精细活。
关键指标：整个流水线的延迟通常控制在10~20行以内（对于1080p分辨率）。超过这个范围，视频通话的实时性就会受影响。我做过一个项目，流水线延迟到了30行，结果画面明显滞后，被客户骂了一顿。
好了，这一章的内容就到这里。ISP流水线的整体框架，说白了就是一条从RAW到YUV/RGB的加工线。前端洗数据，后端做美化。记住这个核心思想，后面每一章我们都会深入每个模块的硬件实现细节。