1. 高通相机架构概览
做高通平台算法移植，第一件事就是搞清楚相机数据到底怎么流的。我刚开始接触高通平台时，面对一堆缩写——ISP、TFE、ICP、CamX、mm-camera——说实话，头都是大的。但后来发现，只要抓住一条主线：数据从传感器进来，经过硬件流水线处理，最后交给算法模块做后处理，整个架构就没那么吓人了。
这一章，我带你把高通相机架构的骨架摸清楚。后面讲双摄融合、夜景模式时，你才知道算法该插在哪个环节。
1.1 硬件模块：ISP、TFE、ICP 各司其职
高通平台的相机硬件流水线，说白了就是三个核心模块接力干活。我画了张图，你先看个全貌：
三个模块的具体分工，我整理了一张表：
| 模块 | 全称 | 核心职责 | 我遇到过的坑 |
|---|---|---|---|
| ISP | Image Signal Processor | Bayer 解码、白平衡、去马赛克、色彩校正 | ISP 参数调不好，后面算法怎么跑都救不回来 |
| TFE | Time Filter Engine | 多帧时域降噪、运动补偿 | 运动场景下 TFE 容易产生鬼影，得小心调阈值 |
| ICP | Image Compute Processor | 算法后处理：双摄融合、夜景、HDR | ICP 算力有限，模型太大就跑不动了 |
关键认知：ISP 和 TFE 是硬件固定流水线，算法工程师基本动不了。ICP 才是你施展拳脚的地方——双摄融合、夜景模式、多帧合成，全在这里跑。
1.2 软件框架：从 mm-camera 到 CamX 的演进
高通相机软件框架经历过一次大换代。早期平台用 mm-camera，后来统一迁移到 CamX（Camera eXtension Framework）。
我个人习惯把 CamX 理解成「插槽式」架构——每个算法模块就是一个 UIMG（Use-case Image）节点，你可以往流水线里插、拔、替换。mm-camera 时代可不是这样，那时候改一个算法要动整个 pipeline，耦合得很紧。
mm-camera 时代（老平台）
- 基于
QCamera2HAL，代码在vendor/qcom/proprietary/mm-camera/ - 算法模块写死在 pipeline 里，想加一个新功能？得改一堆代码
- 调试靠 log 和 adb，没有统一的调优工具
- 我当年移植一个双摄算法，光适配不同 sensor 就花了两周
CamX 时代（新平台）
- 基于 Android Camera HAL3，代码在
vendor/qcom/proprietary/camx/ - 使用 CHI（Camera Hardware Interface） 作为统一配置层
- 算法模块通过 UIMG 节点注册，可以动态组合
- 提供 CamX Tuning Tool，调参不用重新编译固件
我的建议：如果你刚接触高通平台，直接学 CamX。mm-camera 已经逐步被淘汰，新项目（SM8550、SM8650 等）全部基于 CamX。别在旧框架上浪费时间。
1.3 数据流：一张图看懂算法在哪插队
算法移植最核心的问题就是：我的代码在哪个阶段被调用？我画了张 CamX 下的典型数据流图：
⚠️ 注意：算法插入 ICP 后，输入输出 buffer 的格式必须跟 CHI 配置一致。我曾经因为 YUV 格式没对齐（NV12 vs NV21），导致算法输出全是花屏，查了两天才发现是 buffer 描述符写错了。
1.4 本章小结：你该带走什么？
这一章内容不少，但核心就三句话：
- 硬件上：ISP 做基础处理，TFE 做时域降噪，ICP 跑算法——你的代码在 ICP 里跑
- 软件上：CamX 是当前主流框架，用 UIMG 节点注册算法，灵活可配
- 数据流上：算法插入点在 ICP 阶段，通过 CHI 配置输入输出格式