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

最新推荐文章于 2025-06-26 22:30:00 发布

转载最新推荐文章于 2025-06-26 22:30:00 发布 · 4.5k 阅读

camera 专栏收录该内容

43 篇文章

订阅专栏

CHIAPI为Android相机应用提供了一种灵活的图像处理方案，旨在克服Camera2/HAL3接口的局限性，允许OEM厂商自定义图像处理流程，利用低延迟硬件实现高效处理。

come from : https://www.jianshu.com/p/80de4a6e478c

一、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 体系结构模式