📚 课程目录第3章高通相机软件栈

3、高通相机软件栈：CamX、Chi-CDK、Chromatix之间的关系，以及调谐文件在系统中的加载与作用

高通平台的相机软件体系并非单一 monolithic 程序，而是由三层相互协作的组件构成：底层驱动框架 CamX（Camera eXtension）、上层可定制框架 Chi-CDK（Camera Hardware Interface - Camera Development Kit），以及贯穿始终的调谐数据仓库 Chromatix。理解这三者的边界与协作方式，是进行相机调谐与产线校准的前提。本章将拆解它们的职责划分、数据流走向，并重点说明调谐文件（.so / .bin）在系统启动和运行时的加载路径与生效机制。

3.1 三层架构的核心职责与边界

高通相机软件栈的设计哲学是“稳定核心 + 灵活扩展”。CamX 作为底层驱动框架，负责与硬件直接交互，管理 sensor、ISP、flash、actuator 等设备节点，并向上提供统一的 pipeline 抽象。它不关心具体的拍照场景或算法策略，只保证数据通路正确、时序可控。Chi-CDK 则构建在 CamX 之上，是厂商进行二次开发的主要入口，负责实现具体的 usecase（如预览、拍照、录像）、feature（如 HDR、夜景、人像）以及算法插件的注册与调度。Chromatix 则是一个独立的调谐数据仓库，它不包含可执行逻辑，而是以数据文件的形式存储所有与图像质量相关的参数，包括 3A 算法系数、色彩校正矩阵、降噪强度、锐化增益、镜头阴影校正表等。

三者的协作关系可以类比为：CamX 是“操作系统”，Chi-CDK 是“应用程序框架”，Chromatix 是“配置文件数据库”。当相机启动时，CamX 负责初始化硬件并创建 pipeline；Chi-CDK 根据当前场景选择 usecase 并加载对应的 feature 逻辑；而 Chromatix 则在 pipeline 建立过程中被查询，为每个 ISP 模块提供其所需的调谐参数。这种分层设计使得高通平台能够在不改动底层驱动的情况下，通过更新 Chromatix 数据或修改 Chi-CDK 逻辑来快速适配不同 sensor 和镜头模组。

  关键理解：CamX 与 Chi-CDK 的边界在于“机制”与“策略”的分离。CamX 提供机制（如何传输数据、如何调度硬件），Chi-CDK 决定策略（何时切换场景、使用何种算法）。Chromatix 则是策略执行所需的“弹药库”，它本身不参与决策，但为决策提供数据支撑。

3.2 调谐文件在系统启动时的加载路径

调谐文件在系统中的加载分为两个阶段：静态加载和动态查询。静态加载发生在相机 HAL 进程启动时，系统会通过 dlopen() 加载位于 /vendor/lib64/camera/ 或 /vendor/lib/ 下的 Chromatix 库文件（通常命名为 libchromatix_<sensor_name>.so）。这个 .so 文件内部包含了该 sensor 所有分辨率、所有模式的静态调谐数据，以结构体数组的形式组织。加载后，CamX 会解析该库的符号表，获取指向各个调谐结构体的指针，并将其注册到全局调谐管理器中。

动态查询则发生在每次 pipeline 创建或流配置变更时。当 Chi-CDK 请求一个特定的 stream 组合（例如 4000x3000 拍照 + 1920x1080 预览）时，CamX 会遍历所有已加载的 Chromatix 数据，根据当前 sensor 的曝光模式、分辨率、帧率、binning 模式等条件，匹配出最合适的调谐参数集。这个匹配过程由 Chromatix 管理器完成，它通过一个 key-value 查找机制，将 sensor 名称、分辨率索引、模式 ID 等组合成查询键，快速定位到对应的调谐块。

加载阶段	触发时机	加载方式	数据内容	典型路径
静态加载	HAL 进程启动	dlopen() 动态库	所有分辨率的静态调谐参数	/vendor/lib64/camera/libchromatix_imx586.so
动态查询	Stream 配置 / Pipeline 创建	哈希表 / 二分查找	当前模式对应的参数子集	内存中的 ChromatixManager
产线校准	产线校准工具运行	文件读写 (bin)	AWB 增益、AF 曲线、Shading 表	/data/vendor/camera/calib.bin

3.3 调谐数据在运行时的作用机制

调谐数据并非一次性全部生效，而是随着 ISP pipeline 的每个 frame 处理过程被逐步消费。以拍照流程为例：当 sensor 输出一帧 RAW 数据后，ISP 首先执行坏点校正（BPC）和镜头阴影校正（LSC），这两个模块的参数直接来自 Chromatix 中的 sensor 特性表。随后，色彩处理模块（如白平衡增益、色彩校正矩阵）会读取当前 AWB 状态，从 Chromatix 中选取对应的色温区间参数。最后，降噪和锐化模块会根据当前 ISO 和曝光时间，从调谐数据中插值计算出合适的强度系数。

值得注意的是，Chromatix 中的数据分为静态参数和动态参数两类。静态参数在编译时确定，例如 sensor 的像素尺寸、CRA（主光线角）、镜头畸变系数等，这些不会随环境变化。动态参数则允许在运行时被覆盖，例如通过产线校准写入的 AWB 增益偏移、AF 马达的无穷远位置修正值等。动态参数通常存储在 /data/vendor/camera/ 下的 .bin 文件中，系统启动时会优先加载这些校准数据，覆盖 Chromatix 中的默认值。

实战经验：在产线校准中，写入 EEPROM 的校准数据与 Chromatix 动态参数是两套体系。EEPROM 中的数据由 sensor 驱动直接读取，用于硬件层面的补偿；而 Chromatix 动态参数则是在 HAL 层生效，用于软件算法的补偿。两者必须配合使用，缺一不可。例如，AF 校准的无穷远 DAC 值写入 EEPROM，但温度补偿系数则放在 Chromatix 动态参数中。

3.4 案例拆解：预览卡顿与调谐文件加载异常

某项目在导入新 sensor 后，出现预览画面明显偏绿且自动对焦失效的问题。初步排查排除了硬件故障，怀疑是调谐文件未正确加载。通过抓取 HAL 日志，发现以下关键信息：

CamX: [ERROR][Sensor] Failed to load chromatix library: libchromatix_ov64b.so
CamX: [WARN][Chi] Use default chromatix parameters for sensor ov64b
Chi-CDK: [ERROR][Usecase] AWB algorithm init failed, using fallback

日志显示 Chromatix 库加载失败，系统回退到了默认参数。进一步检查文件系统，发现 /vendor/lib64/camera/libchromatix_ov64b.so 文件权限为 644，但 SELinux 上下文错误，导致 HAL 进程无法 dlopen。修复方法是将该文件的 SELinux 标签改为 u:object_r:vendor_file:s0，并重启相机服务。修复后，预览颜色恢复正常，AF 功能也正常工作了。

这个案例揭示了调谐文件加载的三个关键检查点：文件是否存在、权限是否正确、SELinux 上下文是否匹配。在产线调试中，如果遇到“部分功能正常但图像质量异常”的情况，应优先检查 Chromatix 加载日志，而不是直接修改调谐参数。

风险提示：切勿在产线校准过程中随意修改 Chromatix 静态参数。静态参数是经过实验室严格标定的，产线环境无法复现实验室的光学条件。产线校准只应写入动态校准数据（如 AWB 偏移、AF 修正值），否则可能导致批次性图像质量下降。

3.5 常见误区与总结复盘

在理解这三层关系时，工程师常犯的误区包括：将 Chromatix 视为可执行代码（实际上它只是数据）；混淆 CamX 与 Chi-CDK 的修改边界（在 CamX 中强行加入业务逻辑会导致升级困难）；忽略调谐文件的加载顺序（必须先加载静态库，再覆盖动态校准）。正确的做法是：将硬件相关参数放入 Chromatix，将场景逻辑放入 Chi-CDK，将平台通用机制保留在 CamX 中。

总结本章核心要点：CamX 提供稳定的硬件抽象与 pipeline 机制，Chi-CDK 承载可定制的场景策略，Chromatix 作为调谐数据仓库为两者提供参数支持。调谐文件的加载分为静态加载和动态查询两个阶段，产线校准数据通过动态参数覆盖默认值。理解这一架构，是后续进行 Chromatix 参数调优和产线校准流程设计的基础。