第二章：AE系统架构——从输入到输出的完整链路
大家好，我是你们的老朋友。今天我们来聊聊AE自动曝光的系统架构。说实话，很多刚入行的工程师会把AE当成一个独立模块来调，结果往往事倍功半。我个人习惯是先把整个架构理清楚，再动手调参数。这样你才知道你调的那个参数，到底影响了谁。
2.1 AE模块的输入与输出
先看最基础的问题：AE模块到底需要什么，又产出什么？
输入信号，说白了就是三样东西：
- 原始图像数据：通常是Bayer格式或者YUV格式的帧数据。注意，这里不是最终输出的图像，而是传感器直接出来的原始数据。我在项目中遇到过有人拿处理后的图像做AE统计，结果曝光一直不稳定——因为图像处理本身会改变亮度分布。
- 传感器增益状态：包括模拟增益、数字增益、曝光时间。这些是当前帧的配置，AE需要知道上一帧用了什么参数，才能决定下一帧怎么调。
- 场景信息：比如帧率、分辨率、是否开启HDR等。这些会影响曝光策略的选择。
输出信号，其实就一个目标：下一帧的曝光参数。具体包括：
- 曝光时间（Exposure Time）
- 模拟增益（Analog Gain）
- 数字增益（Digital Gain）
- 光圈控制（如果有的话）
核心要点：AE的输出不是「目标亮度」，而是「如何达到目标亮度的参数组合」。这个区别很重要——你调的是参数，不是结果。
2.2 3A算法框架的协同
AE不是孤军奋战的。它和AWB（自动白平衡）、AF（自动对焦）组成了所谓的「3A铁三角」。你想想看，这三个模块如果各调各的，画面会乱成什么样？
我习惯用一个比喻来理解它们的协同关系：
- AE 负责「亮度」——画面够不够亮
- AWB 负责「颜色」——画面偏不偏色
- AF 负责「清晰度」——画面清不清晰
但它们之间是有耦合的。举个例子：
- AE调整曝光时间，会影响AWB的统计结果（因为不同色温下亮度分布不同）
- AF的镜头移动，会改变进光量，进而影响AE的亮度判断
- AWB的增益调整，会改变RGB通道的权重，间接影响AE的亮度统计
我的经验：在调试时，我建议先锁定AWB和AF，只调AE。等AE稳定了，再放开AWB，最后调AF。这样能避免三个模块互相干扰，排查问题也容易得多。
2.3 AE控制环路——反馈系统的核心
AE本质上是一个闭环反馈系统。它的工作流程是这样的：
- 传感器采集当前帧
- ISP统计模块计算当前帧的亮度统计值（比如平均亮度、直方图）
- AE算法根据目标亮度和当前亮度的差值，计算新的曝光参数
- 将新参数写入传感器寄存器
- 传感器用新参数采集下一帧
- 重复步骤1-5
这个环路里有一个关键概念叫收敛速度。说白了就是：从场景变化到画面稳定，需要多少帧？
我曾经遇到一个项目，AE收敛太慢，用户拿着手机从室内走到室外，画面要闪好几秒才稳定。后来发现是反馈环路的增益系数设得太小了。调大之后，收敛快了，但又出现了过冲——画面先亮过头，再暗回来。嗯，这就是典型的PID参数没调好。
避坑指南：我曾经在某个项目中，把反馈环路的更新频率设成了每帧都更新。结果画面一直在「亮-暗-亮-暗」之间震荡，像呼吸灯一样。后来改成每3帧更新一次，才稳定下来。记住：不是越快越好，稳定才是第一位的。
2.4 硬件与软件的划分
AE的实现，到底是放在硬件里做，还是用软件做？这个问题没有标准答案，取决于你的产品定位和成本预算。
我整理了一个对比表格，方便你理解：
| 维度 | 硬件实现 | 软件实现 |
|---|---|---|
| 速度 | 快（几微秒到几毫秒） | 慢（几毫秒到几十毫秒） |
| 灵活性 | 低（算法固化后难改） | 高（可以随时更新算法） |
| 功耗 | 低 | 高（CPU/GPU占用） |
| 典型场景 | 安防摄像头、行车记录仪 | 手机、相机、AI摄像头 |
我个人习惯的做法是：统计部分放硬件，决策部分放软件。为什么？
- 统计（比如计算直方图、平均亮度）是重复性工作，硬件做又快又省电
- 决策（比如判断场景类型、选择曝光策略）需要灵活性，软件做方便迭代
你想想看，如果所有逻辑都写死在硬件里，一旦发现某个场景曝光不准，就得重新流片——那成本可就大了去了。
2.5 知识体系总览
下面这张图是我自己画的AE系统架构图，涵盖了本章的核心内容。你可以把它当作一个「地图」，后续章节都会围绕这张图展开。
这张图里，我特意把「硬件统计模块」和「软件决策模块」分开画，就是想强调：AE的架构设计，本质上是在「速度」和「灵活性」之间做取舍。你不需要追求极致的硬件化，也不需要全盘软件化——找到适合你产品的平衡点，才是关键。
一个小建议：如果你刚开始接触AE，不妨先从软件实现入手。等你把算法逻辑跑通了，再考虑把统计部分搬到硬件上。这样既能快速验证，又能保证最终产品的性能。
公众号:蓝海资料掘金营，微信deep3321