Android : Camera之CHI API
一、CAM CHI API功能介绍：
CHI API建立在Google HAL3的灵活性基础之上， 目的是将Camera2/HAL3接口分离出来用于使用相机，是一个 完全灵活的图像处理驱动程序（摄像头硬件接口）。HAL3是围绕摄像机管道请求控制而设计的，以提供完整的功能处理对最终用户的控制，但仅限于请求边界。 CHI旨在提供更细粒度的控制，以及访问ISP内的处理引擎。使得OEM和最终用户可以利用CHI API 在相机驱动程序中实现自定义图像处理。如：通过 高通的ISP，高通®Adreno™GPU和高通®Hexagon™DSP等实现相应的Use Cases。
1.Qualcomm Spectra 2xx相机驱动程序有五个关键的可定制组件，使OEM能够充分利用CHI进行相机应用开发：
SRE实战 互联网时代守护先锋，助力企业售后服务体系运筹帷幄！一键直达领取阿里云限量特价优惠。- CHI Override 模块补充了Google HAL3接口，允许符合HAL3标准的相机应用程序直接控制图像处理流水线的生成、引擎选择和多帧控制等。
- CHI拓扑结构 由xml进行配置，旨在将任意的计算管道构造用于图像处理，管道可以由QTI或扩展节点提供的ISP（FF-ISP）固定功能模块组成，由摄像机驱动程序堆栈外部控制。
- CHI节点 扩展是CHI的进一步扩展，提供了方便的hooks方法来简化CPU，GPU（通过OpenCL，OpenGL ES或Vulkan），或 DSP（通过OpenDSP，FastCV™软件开发套件或自定义编程）上的额外处理。 自定义节点可以指定私有供应商标记，用于被应用使用以及 与CHI FF-ISP节点或其他扩展节点交互。
- CHI统计信息覆盖（包括3A）机制允许覆盖任何QTI的默认值统计算法，且无需改驱动程序。外部统计算法可以存储私有数据，也可以由自定义节点访问。
- CHI传感器XML允许设备制造商为其特定硬件配置参数，包括相机模块，图像传感器， 执行器，电子可擦除可编程只读存储器（EEPROM）和 闪存组件。
2.关键术语：
Use case：相机管道的特定配置，实现了良好的定义的功能，例如，带有ZSL的20 MP快照和2k上的预览显示是就是一个用例。 CHI API允许开发者在底层硬件的限制范围内自行配置use case，并且不需要修改驱动。
Session：相机管道被创建开始处理图像到被销毁的过程，称之为会话，同时可以存在多个会话。
Request ：请求处理从图像传感器中提取的数据帧，或从内存中提取的数据帧，驱动处理结果必须返回到相机应用程序。
Sub-request ：将单个HAL3请求分解为多个CHI子请求操作，子请求的结果不会从驱动程序中返回出去，而是合并为单个结果给原始请求。子请求一般用于启用Camera2的某些功能，例如HDR、多帧后处理等。
Stream：
Per-session settings：影响相机管道处理的设置， 会话开始后就无法被更改。例如， 允许图像稳定处理。
Per-request settings：影响各个请求的设置。例如，设置手动曝光值。
Topology：有向无环图（DAG）由一系列处理节点和一组链接组成，它描述了那些正在被节点处理的缓冲区。拓扑通过XML文件指定。
Engine：用于处理数据的硬件。 如Spectra ISP，Snapdragon CPU， Adreno和DSP 是CHI API可用的引擎示例。
Node：像机管道中的逻辑功能块（节点），节点链接在一起形成拓扑。在初始版本中 CHI API，ISP外部的所有节点都通过CPU代码通过本地API（OpenCL和FastCV之类的引擎）调用，Chi API可以在将来扩展到允许在不重用本地api的情况下缓存和重用硬件命令。
Pipeline：启用数据操作的唯一上下文。每个管道都可以维护自己的状态跨多个请求，而不受其他管道的影响。管道利拓扑结构定义Engine使用和数据处理流程。
Statistics：包括3A算法，用于自动控制图像传感器和相机ISP实现更好的图像质量。这些特定领域的算法被处理成为CHI API的专用部分。
Live stream：从图像传感器接收数据的处理进程，不能修改之前请求的任何数据。如果处理速率和传感器数据传输不匹配则会移至Offline stream。
Offline stream：不从图像传感器直接获取数据处理的进程，在Chi API中，Offline stream可以与Live stream成对存在而不造成额外的延迟，处理结果可以返回到相机。
二、CHI 体系结构模式
1.基本拓扑关系图
2.Chi 硬件接口
谷歌HAL3的扩展接口，允许通过请求调整拓扑结构和低延迟控制。
一些谷歌HAL3接口使用的特性如下:
- 自定义ZSL
- 多帧请求生成 和 处理
- 图像稳定
- 低延迟后处理
CHI驱动程序提供默认节点来启用相机use cases。oem厂商可以在现有的CHI驱动上添加功能，以获得独特的相机体验。这是一个简单而强大的接口，可以在相机pipeline中无缝添加图像处理功能。
4.拓扑图形 CHI拓扑XML是相机use cases的拓扑框架描述（DAG：有向无环图），它在HAL进程初始化时被加载。它本质上是一个键值+数据的存储结构，其中的键值主要用于从可用集中选择特定数据，键值代表每个会话设置+集合的流。高通为常见use cases提供了默认拓扑XML(titan17x_usecases.xml)。oem厂商可以编辑默认XML和创建自定义拓扑XML，CHI API也提供了一个接口来显式地选择自定义拓扑。
5.use case示例
下面的时序图大致描述了一个CHI的use case调用流程：
....(后面阅读源码，通过uml试试画出来)
- Nodes:每个请求都会访问所有节点，也可以忽略某些请求不需要的节点。
- Links: 链接指定了所有使用到的缓冲区格式和大小(无论作为源还是接收器)。节点之间的链接可以根据父节点上输出端口的最小数量指定尽可能多的格式，以及在子节点上的接收端口的数量。
- Buffers: Topology 控制给定类型的缓冲区数量，应用程序可以根据需要多少缓冲区微调内存使用情况以减少处理延迟。
三、Metadata
CHI中的沟通渠道可以分为以下几类:
(1)Data 传递给应用程序 (2)Data 传递到加工管道 (3)Inter-node 沟通使用发布和订阅机制 ChiNode1 ↔ ChiNode2 使用 Android tags/ChiVendorTags ChiNode1 ↔ ExtNode1 使用 Android tags/ChiVendorTags / ExtCompVendorTags ExtNode1 ↔ ExtNode2 使用 Android tags/ChiVendorTags/ExtCompVendorTags
元数据标签可以是预定义的Android tags，也可以是定制的vendor tags。元数据标签使CHI内外的组件能够与每个组件通信另外还有面向应用程序的摄像头API。在CHI中，Androidtags通过不可变值来预定义，而vendor tags不能是固定绝对值，要取决于目标扩展组件的数量和类型。CHI使用动态索引(base +偏移量)来使供应vendor tags组件能够彼此通信。
元数据标记ID是一个32位的值，它被限制在特定的部分中。每一个section以0x1_0000偏移量开始。标记空间的范围从0x0000_0000到0x8000_0000保留给Android tags，供应商部分是预定在0x8000_0000之后开始。在初始化期间，当CHI扫描目标中的可用组件时，它为发布自定义组件的每个组件分配一个vendor tags，组件通过Base + Offset枚举, 基地址由CHI分配。
metadata空间示例，包括ChiVendorTags和两个ExtCompVendorTags(EXT_COMP_1和EXT_COMP_2)，如下图所示：
