多摄像头 HAL 实现实战：Logical Camera 与 Sensor Fusion 架构详解

关键词：
Logical Camera、Multi-Camera HAL、Sensor Fusion、DualCam、HAL3、Meta同步、场景切换、平台适配

摘要：
在移动影像系统中，Dual/Triple Camera 乃至 Periscope/ToF 等多模组配置日益成为标配，而 Android Camera HAL3 框架已提供 Logical Camera 支持用于屏蔽底层物理 Sensor 差异并完成图像融合输出。本文将基于实际平台实践，深入讲解 Logical Camera 的构建路径、Sensor Fusion 模型的执行流程、跨模组参数管理策略及其在 QCOM/MTK 平台中的工程实现。文章将以高质量项目经验为基础，详细拆解从 metadata 同步到帧时序控制的关键调优路径，适用于主副摄融合、景深对焦、多焦段无缝切换等典型应用。

目录规划：

  1. 多摄系统 HAL 架构总览：从 Physical Camera 到 Logical Camera 抽象
  2. Logical Camera Metadata 合成机制：设备能力聚合与动态更新
  3. Fusion 模型设计：帧对齐、几何校正与图像融合路径
  4. 多 Sensor 流协同：流同步、帧标记与 HAL 层封装逻辑
  5. 实战案例：Dual Wide+Tele 变焦融合、景深估算与虚化应用
  6. 多平台对比分析：QCOM QCamera3 + StaticMetadata、MTK Cam3 Fusion Flow
  7. 调试技巧与典型问题排查：同步偏移、帧乱序、metadata 缺失
  8. 演进趋势：向 AI 引导式 Fusion Pipeline 与语义层协同感知过渡

1. 多摄系统 HAL 架构总览：从 Physical Camera 到 Logical Camera 抽象

多摄像头系统是近年来智能终端影像系统进化的核心方向，从早期单一摄像头配置逐步过渡到 Dual（主+副）甚至 Quad Camera（主+广角+长焦+ToF）的复杂系统。Android 从 Android 9（API 28）开始通过 HAL3.2 及其后的规范，正式引入 Logical Camera 架构 ，以支持上层通过单一 CameraId 使用多个底层 Sensor 实现融合图像输出、变焦无缝切换、景深估算等功能。

在架构上，Camera HAL 层会将多个 Physical Camera 封装进一个 Logical Camera 设备节点（如 CameraId=0 实际对应 Physical CameraId=0 和 2），其内部维护了各 Sensor 的能力集（Static Metadata）、支持的配置组合（stream configuration map）、以及切换条件（如 zoom ratio 范围、FOV 角度差等）。

核心流程包括：

  • HAL 实现中注册多个 physical devices；
  • 创建一个 Logical CameraId 并设置其 android.request.availablePhysicalCameraIds ；
  • 实现 HAL3 中的 getPhysicalCameraMetadata() 、 processCaptureRequest() 支持；
  • CameraService 在上层调用时统一管理。

该机制有效隔离了复杂的 Sensor 调用逻辑，使上层 Framework 与 App 无需关心底层结构，实现从软件角度的 Camera 模组抽象聚合。

2. Logical Camera Metadata 合成机制：设备能力聚合与动态更新

在构建 Logical Camera 的过程中，metadata 的聚合是最关键的一步。Android 要求 Logical Camera 的静态属性（static metadata）不仅要具备物理摄像头的能力集（如分辨率、帧率、format），还要提供融合能力描述（如 zoom 支持范围、场景切换指示等）。

合成策略一般分两种：

  • 静态聚合 ：在 construct_default_request_settings 和 get_camera_metadata 中生成统一的 metadata，字段如 android.control.availableFocalLengths 会融合各物理镜头焦距；
  • 动态能力组合 ：对每帧请求，在 processCaptureRequest 中读取 android.logicalMultiCamera.physicalId ，将 metadata 更新为当前选中的 Sensor 结果，用于实时参数传递。

常见的字段合成策略如下：

Metadata 字段聚合方式举例
availableStreamConfigurations合并去重支持 YUV/MJPEG/RAW 三模组共存
availableFocalLengths排序合并[1.0, 1.5, 3.0]
zoomRatioRange基于物理 FOV 计算1x - 6x
availablePhysicalCameraIds明确列出[“0”, “2”]

此外，针对不同平台（如 QCOM 的 QCamera3HardwareInterface::generateStaticMetadata 或 MTK 的 MetadataProvider::create() ），需要在 HAL 初始化阶段精确合并多 Sensor 能力，并标记每个 physical id 的 stream 能力，以供 CameraService 调度和参数下发。

3. Fusion 模型设计：帧对齐、几何校正与图像融合路径

在 Logical Camera 的图像输出中，Fusion 模型是核心能力模块，直接影响图像质量与多摄协同的体验。Fusion 模型主要涉及三大子模块：帧对齐、几何校正与图像融合。

3.1 帧对齐机制（Temporal Alignment）

当多个物理传感器输出图像时，必须确保它们拍摄的内容在时间上高度一致，避免因不同帧产生“鬼影”或融合失败。

  • 同步方案 ：

    • 硬件同步（Hardware Trigger Sync）：部分平台（如 QCOM/QTI）支持 sensor 外部同步信号（Master/Slave 模式）；
    • 软件层标记帧戳（Timestamp Align）：通过 HAL 或 ISP 布局延迟，使用同步帧戳进行校验。

  • Buffer Match 策略 ：

    • Fusion 模块仅处理 timestamp 相近或差值在可接受范围内的帧；
    • 若某 sensor 帧缺失，将触发降级策略（如 fallback 到主摄像头单帧处理）。
3.2 几何校正机制（Geometric Correction）

不同物理 Sensor 模组的安装位置不可能完美对齐，且存在视角差异、成像畸变（尤其是广角）等问题。HAL 层需先进行几何对齐操作。

  • 标定数据 ：Lens distortion、Principal Point、Rotation Matrix 等参数来自工厂标定或场景自学习；

  • Warping 处理 ：

    • 通常交由 ISP 或 GPU 后处理模块完成；
    • 在部分平台（如 MTK）可由 AI ISP 中的校正模块执行实时补偿。
3.3 图像融合路径（Fusion Pipeline）

融合路径设计取决于目标输出类型：静态图（Snapshot Fusion）还是视频流（Preview Fusion）：

  • 静态图融合 ：

    • 多帧对齐后按像素级融合（如多曝光权重或深度辅助融合）；
    • 常用于 SuperResolution、Zoom Fusion、夜景。

  • 视频流融合 ：

    • 实时低延迟 Pipeline，需保证在 1-2 帧延迟内完成；
    • 多使用 AI 模型推理，如 FusionNet , HDRNet 、深度图辅助的帧选择器。

不同平台融合路径实例：

  • Qualcomm 平台通过 QCamera3HardwareInterface 控制 Fusion Module；
  • MTK 使用 HAL3 架构中的 DualCamStream 控制双 sensor 的数据融合；
  • Samsung 多采用自研 AI Fusion Pipeline 实现 108MP + UltraWide 场景协同。

4. 多 Sensor 流协同：流同步、帧标记与 HAL 层封装逻辑

为了让多个物理摄像头同时工作，HAL 层必须承担流协同的调度角色，包括帧流的生命周期管理、标记机制与回调封装。

4.1 请求生成与流同步（Request Sync）
  • 上层传入的 CaptureRequest 会被 HAL 拆分成多个 SubRequest ，分别下发给各 physical camera；
  • HAL 会将所有 sensor 的输出 Buffer 拉齐，形成一个 FrameBundle （平台定制名称可能不同），再进行进一步融合。
4.2 帧标记机制（Frame ID & Metadata Tagging）
  • 每一帧 HAL 层都需要添加唯一帧号（frameNumber）与 sensor 来源 ID（physicalId）；
  • 在 process_capture_result() 中返回 metadata 时，需附带 source 信息，方便上层 camera service 与 framework 区分。
4.3 多路流封装结构
  • HAL 需要构建双层结构：LogicalStream → PhysicalStream → StreamBuffer；
  • Android 11+ 中增加了 Camera3StreamInterface 支持多路绑定，QCOM、MTK 等厂商则通过自研结构（如 DualCamStreamManager ）管理。

举例：

camera3_capture_request_t {
    ...
    uint32_t num_phys_cam_settings;
    const char* physical_camera_id[N];
    camera_metadata_t* phys_cam_settings[N];
}
4.4 典型平台逻辑封装
  • QCOM ：由 QCamera3DualFOV 或 QCamera3FusionFactory 负责 fusion decision；
  • MTK ：由 MtkCam::PipelineModel 调度主副摄与 Fusion 控制器；
  • 三星 ：自研 HAL 对每个 CameraId 维护物理与逻辑绑定关系。

5. 实战案例：Dual Wide+Tele 变焦融合、景深估算与虚化应用

在实际项目中，Dual Wide+Tele 架构已成为中高端手机拍照系统的常见配置，其核心目标是实现连续变焦、清晰远摄与自然背景虚化。

5.1 架构描述
  • Wide 模组 ：一般为 26mm 等效焦段，主摄 Sensor；
  • Tele 模组 ：50~80mm 等效焦段，配合对焦马达和更小的视角；
  • HAL 逻辑相机 ：封装为同一 CameraId，通过 zoomRatio 实现透明切换与融合。
5.2 变焦融合实战路径

变焦融合的关键是避免明显的切换断层，同时确保输出图像在清晰度与颜色上的一致性。

  • Fusion Trigger 机制 ：

    • 根据 zoomRatio 范围设置多个融合区间（如 1x 1.8x Wide、1.8x 3x Fusion、3x~5x Tele）；
    • 使用基于 GYRO 的 feature alignment 进行帧融合。

  • 图像配准与融合算法 ：

    • 常用 Feature Match + Perspective Warp + Weighted Merge ；
    • AI 方案如 ZoomNet , ZoomRefine 融合神经网络，提升边缘保真与锐度。

  • 平台调试经验 ：

    • QCOM 平台需通过 QCamera3HardwareInterface::handleZoomFusion() 管理主副摄输入；
    • MTK 则依赖 MultiCamRequestProcessor 统一调度两个 pipeline 并维护流同步。
5.3 景深估算与背景虚化

以 Dual Cam 为输入进行立体对拍，实现 DOF 估算与虚化是另一大应用路径。

  • 景深估算路径 ：

    • 通过两路 Sensor 间视差图估算 Z-depth；
    • 基于标定数据进行基线校正与点云稀疏补全。

  • 背景虚化算法 ：

    • AOSP 基础方案使用 bokeh 模块 + DOF map；
    • 厂商通常自研 AI 模型（如 QTI 的 PortraitNet ，MTK 的 DepthRefine ）增强边缘分割与真实光学模拟。

  • 工程要点 ：

    • 校准精度决定 DOF 稳定性，推荐加入工厂 PnP 标定流程；
    • HAL 层需精细控制两个摄像头间曝光匹配、帧同步及色彩校准。

6. 多平台对比分析：QCOM QCamera3 + StaticMetadata、MTK Cam3 Fusion Flow

多摄像头系统的实现因 SoC 架构差异，在 HAL 层呈现出不同的接口设计和流程策略。以下对比高通与联发科两个主流平台在 HAL3 多摄实现上的异同：

6.1 QCOM 平台（QCamera3）

  • 核心模块 ： QCamera3HardwareInterface 、 QCamera3ProcessingChannel 、 QCamera3StreamMem ；

  • Metadata 管理 ：

    • 使用 vendor_tag_ops_t 注册自定义 Metadata（如 QCAMERA3_DUALCAM_CONTROL）；
    • 每个 request 关联不同的 physical_camera_metadata_t 。

  • Fusion 控制机制 ：

    • 通过 dualcam_control_t 传入 zoomRatio、场景类型；
    • 在 QCamera3DualFOVSensor 中调用 sensor-specific fusion lib。

  • 优势 ：

    • 接口统一，适配代码成熟；
    • 配合 SnapshotPostProc 可快速接入超分辨率与多帧合成。
6.2 MTK 平台（Cam3 架构）

  • 核心组件 ： CameraDevice3Session , PipelineModel , DualCamRequestProcessor ；

  • Fusion 流程 ：

    • 在 AppStreamMgr 中拆分与重组 Dual Sensor 请求；
    • 通过 FeatureSettingPolicy 设置具体的融合策略（Zoom、Portrait、Night）。

  • 自研模块优势 ：

    • 支持更复杂场景（三摄、四摄）；
    • 配合 DepthMapNode , FusionProcessor 执行硬件级景深估算。

  • 挑战 ：

    • HAL3 层复杂度更高，调试依赖平台内核驱动协同；
    • Feature 模块划分需大量定制，文档覆盖不完整。

在项目落地过程中，选择平台需综合考虑硬件特性、Fusion 算法成熟度、调试工具链支持等，建议优先从双摄基础场景切入，逐步扩展至超广角、微距与潜望式长焦等复杂组合。

7. 调试技巧与典型问题排查：同步偏移、帧乱序、metadata 缺失

多摄系统由于存在多条独立的数据流，常见问题集中在同步、帧一致性与元数据传递错误等方向，以下是各类问题的典型排查路径：

7.1 帧同步偏移

症状 ：图像画面出现双重影、变焦场景卡顿、景深图异常。

排查路径 ：

  • 检查主/副 Sensor 是否使用相同的外部触发（EXT CLK/VSYNC）；
  • HAL 层对 frame_number 管理是否一致，是否存在重复或跳号；
  • 使用平台 Trace 工具（如 MTK 的 CamSysLog 、QCOM 的 camxtrace ）查看两个 pipeline 的时间戳对齐情况。

解决思路 ：

  • 引入基于 GYRO/AE 统计的帧差容忍机制；
  • 在 CaptureResult 中增加同步容错字段；
  • 调整 BufferQueue 策略，允许 pipeline 轻度缓冲并重排序。
7.2 帧乱序问题

症状 ：视频流输出卡顿，融合帧出现抖动或错误帧。

排查路径 ：

  • HAL 层 process_capture_result() 的发送顺序与 frame_number 匹配；
  • camera3_stream_buffer 的 streamId 对应关系是否错乱；
  • 检查 ISP 输出 buffer index 与 Fusion 输入匹配是否正确。

调试建议 ：

  • 设置 dump 开关，将 Fusion 输入帧缓存与结果帧导出比对；
  • 引入 timestamp_tracker 检测前后台帧时间戳是否错位。
7.3 Metadata 缺失或不一致

症状 ：AI 模型无法正确执行曝光/聚焦推理，虚化失败。

关键点检查 ：

  • Request metadata 中是否完整配置 physical stream info；
  • 检查 HAL 层是否正确注册了 logical_multi_camera_active_ids 与 physical_camera_metadata_map ；
  • 是否存在某一路 Sensor 未返回 Frame metadata（如 AE/AF 状态）。

应对方案 ：

  • HAL 层进行 fallback 合成，自动构造缺失的 metadata；
  • 对 sensor pipeline 增加超时处理与默认值注入机制。

这些调试技巧和工程化手段，对于复杂多摄系统的稳定性验证至关重要，建议构建标准的调试流程链路与日志模板，以便快速复现与定位问题。

8. 演进趋势：向 AI 引导式 Fusion Pipeline 与语义层协同感知过渡

未来多摄 HAL 架构的演进正逐步从传统的几何与时间对齐算法，过渡到由语义与 AI 模型驱动的智能感知系统。

8.1 传统 Fusion Pipeline 的局限
  • 缺乏对场景内容的理解，仅基于像素相似性与几何对齐；
  • 对复杂变光/变焦/非刚体物体处理能力弱；
  • 需要大量的硬件协同（对时/对焦）支持。
8.2 AI 引导式架构发展方向

  • AI Scene Aware Fusion ：

    • 利用神经网络预测不同区域最优 fusion 策略（如人物前景 sharp、背景 soft）；
    • 输入数据可包括 depth map、segment mask、scene classification 等。

  • 语义级感知联动 ：

    • HAL 层结合 AI 引擎，动态选择使用单摄/双摄；
    • 增加与 Scene Intent 的协商机制（如人像、建筑、夜景）决定 Fusion 流路径。

  • 异构模组间策略协调 ：

    • 结合 UWA + Wide + Tele 架构，引入场景感知的 Zoom Graph；
    • 实现“视角协商”与“特征优选”，动态决定主 Sensor 输出源。
8.3 工程趋势
  • QTI 已在 SnapFusion 中实现 AI Zoom Path Prediction；
  • MTK 在 DualCam AINR 架构中引入 HDR-aware Depth Fusion ；
  • Google AOSP 已将 SceneMode 、 VendorTag 标准化，支持 HAL-Framework-AI 模块多维协同。

总体来看，Camera HAL 不再是单纯的数据转发者，而正逐步进化为“场景调度器”，需要结合 ISP 能力、AI 模型与多 Sensor 输出，构建更智能、具备理解力的图像处理平台。

本文转自 https://jc-performance.cn//online/0953_148658060.html，如有侵权，请联系删除。