Android Camera原理之camx hal架构之cam chi

一、CAM CHI API功能介绍：

Android开发了相机硬件接口，允许OEM生产 为最终用户提供高质量的相机解决方案。 Camera2 java API的组合 使用HAL3接口进行相机应用程序开发可以提供足够的灵活性 支持各种用例。大多数用例都可以实现 Camera2 / HAL3。但是，其他引擎上的延迟或潜在低效处理 例如CPU，GPU或DSP，当java层负责时可能是不可接受的 用于控制执行流程。 OEM可以更多地实施自定义 通过绕过HAL3接口，并直接修改摄像头驱动程序。

Camera2 / HAL3接口有一些限制，可以阻止OEM 使用它作为通用图像处理界面：

• 没有接口可以访问ISP内的各个固定功能引擎
• 没有明确请求给定用例的处理流程的接口
• 使用案例定义松散，可以解释预期的处理过程 不同
• 所有请求必须在开始之前通过框架返回结果 依赖请求
• 根据预期的使用情况调整管道深度;优秀人数 对于大多数HAL3相机驱动来说，实现复杂处理管道的请求太大了
• 应用程序没有“快速路径”，只需要最少的处理和最少的处理 潜伏
  CHI API旨在分离Camera2 / HAL3界面以使用相机，和 使用完全灵活的图像处理驱动程序来补充它。 CHI图像处理 驱动程序可作为独立的处理实体访问，具有使用图像的能力 来自传感器或存储器的数据。为了让Spectra能够保持向后 - 兼容现有的Camera2 / HAL3接口，一个简单轻便的HAL3驱动程序可以转换 HAL3调用适当的CHI调用。 HAL3驱动程序是生成所有工作的地方 实现了相机用例;用例通过CHI API调用实现。

提供了一个接口，允许OEM修改默认的Qualcomm Camera 用例实现。此修改允许OEM使用Camera2或HAL3 应用程序，仍然可以获得CHI提供的灵活性。这些覆盖是 旨在允许OEM在任何可用的上实现任何类型的图像处理 引擎，具有低延迟，无需跨越协调同步 多个引擎。

CHI API建立在Google HAL3相机界面的现有灵活性之上。 HAL3是围绕摄像机管道的显式每请求控制而设计的，以提供完整的功能 处理对最终用户的控制，但仅限于请求边界。 CHI旨在提供更细粒度的控制，以及访问ISP内的处理引擎。这个 接口允许OEM和最终用户利用低延迟硬件和 Qualcomm Technologies，Inc。（QTI）在Qualcomm®上提供的软件路径 Snapdragon™处理器平台，适用于相机和通用图像处理 应用。

Qualcomm Spectra 2xx相机驱动程序有五个关键的可定制组件 使OEM能够充分利用CHI进行相机应用：

• CHI覆盖模块补充了Google HAL3界面以允许显式 图像处理流水线生成，显式引擎选择和多帧 控制任何符合HAL3标准的相机应用程序。
• CHI管道允许构造任意计算管道以进行处理 图片。管道可以由固定功能ISP块（FF-ISP）组成，由提供 QTI或扩展节点，它们在摄像机驱动程序堆栈外部受到控制。对于 Camera2 / HAL3实现，一个XML帮助文件指定图形，其中 匹配现有的Camera2 / HAL3用例。直接打电话给CHI可以 以编程方式生成管道。
• CHI节点扩展是CHI的进一步扩展，提供方便的钩子 简化CPU，GPU（通过OpenCL，OpenGL ES或Vulkan）的处理，或 DSP（通过OpenDSP，FastCV™软件开发套件或自定义编程）。 自定义节点可以指定应用程序使用的私有供应商标记，以及 与CHI FF-ISP节点或其他扩展节点交互。
• CHI统计信息覆盖（包括3A）允许机制覆盖任何QTI的默认值 统计算法，无需更改驱动程序。外部统计算法可以 存储私有数据，也可以由自定义节点访问。
• CHI传感器XML允许设备制造商为其定义参数驱动的驱动程序 他们的特定硬件组件，包括相机模块，图像传感器， 执行器，电子可擦除可编程只读存储器（EEPROM）和 闪存组件。

1.1 关键术语

Use case：相机管道的特定配置，实现了良好的 定义的功能。例如，带有ZSL的20 MP快照和2k上的预览 显示是一个用例。 CHI API旨在指定任何可以想象的用户 - 定义的用例，在底层硬件的限制范围内，并且不需要 驱动修改。

Topology：有向无环图（DAG），表示要完成的处理 通过管道。 DAG由一系列处理节点和一组链接组成， 它描述了那些节点正在处理的缓冲区。

Engine：可用于处理数据的硬件。 Spectra ISP，Snapdragon CPU， Adreno和DSP是CHI API可用引擎的示例。

Node：摄像机管道中的逻辑功能块，执行 单引擎。节点链接在一起形成拓扑。在初始版本中 CHI API，ISP外部的所有节点都通过CPU代码调用，后者调用 原生API。本机API驱动OpenCL和FastCV等引擎。 CHI API 可以在将来进行扩展，以允许缓存和重用硬件命令 不重用本机API。

Pipeline：包含单个经过验证的拓扑的可重用容器。管道是 驱动程序用来理解使用的引擎和数据处理流程。

Session：一个具有1-n个管道的不可变容器。会话管理所有 硬件资源以及附加到其上的所有管道的待处理请求。每次会议 跨多个请求维护自己的状态，而不会影响其他会话。 停用会话（不破坏会话），释放分配给的所有资源 它。支持多个并行会话。

Request：触发管道处理数据的操作。这可以是一个请求 处理从图像传感器拉出的数据帧，或处理来自存储器的数据。 驱动程序必须为每个请求返回结果。 HAL3和CHI请求得到管理 分别。

Sub-Request：将单个HAL3请求分解为多个CHI请求的操作。 子请求的结果不会在驱动程序之外返回;相反，他们是 合并为单个结果，对应于原始请求。子请求 用于启用Camera2功能，例如HDR，其中多次曝光更改 传感器需要生成单个图像，或多帧后处理， 合并多个图像以创建单个输出图像的位置。子请求是 作为用例管理的一部分实现，可供CHI覆盖使用 模块。

Stream：一系列具有相同大小和格式的缓冲区，用于 处理图像数据。可以将多个不同类型的流指定为输入和 输出到摄像机管道。这组流是定义a的关键组件 Camera2 / HAL3用例。

Per-session settings：生命周期的处理管道的设置 会话。会话开始后，无法更改这些设置。例如， 允许图像稳定处理。

Per-request settings：影响各个请求的设置。例如，手动 暴露值。

Statistics：算法包括3A，用于自动控制图像 传感器和相机ISP实现更好的图像质量。这些特定于域的 算法作为CHI API的专用部分处理。

Live and realtime stream：处理从中接收数据的任何配置 图像传感器，不能修改先前请求中的任何数据。处理那个 不适合传感器数据速率可以移动到离线流中。

Offline stream：处理未从中接收数据的任何配置 成像传感器。在CHI API中，离线流可以与实时流配对 没有额外的延迟。离线流的结果可以返回到摄像机 应用。

二、CHI 体系结构模式

camx chi 基本拓扑图.jpg