AE收敛与稳定性：收敛速度、防抖策略与Flicker抑制
AE（自动曝光）这东西，说白了就是让画面亮度“刚刚好”。但“刚刚好”这三个字，背后全是坑。收敛慢了，用户觉得卡顿；收敛快了，画面来回晃；遇到灯光频闪，整个画面像在呼吸。今天我就把这三个核心问题掰开揉碎讲清楚。
4.1 AE收敛速度：快与慢的博弈
收敛速度，就是AE从当前亮度跑到目标亮度的时间。太快会 overshoot，太慢用户骂街。我习惯把收敛过程分成三个阶段：粗调、细调、锁定。
| 阶段 | 目标 | 步长策略 | 典型耗时 |
|---|---|---|---|
| 粗调 | 快速接近目标亮度 | 大步长，每帧调整2~4档 | 3~5帧 |
| 细调 | 消除过冲，进入目标区间 | 中步长，每帧调整0.5~1档 | 5~10帧 |
| 锁定 | 稳定在目标亮度±5%内 | 小步长，每帧调整0.1~0.3档 | 持续 |
关键指标：收敛时间通常要求≤15帧（30fps下约0.5秒）。超过这个数，用户就能感知到“亮度在变”。
我在项目中遇到过一个问题：室内转室外场景，AE粗调阶段直接跳了6档，结果画面先过曝再拉回，用户反馈“闪了一下”。后来我加了帧间亮度变化限制，单帧最大调整不超过3档，问题就解决了。
4.1.1 步长自适应算法
步长不能死板。我常用的策略是：
// 伪代码：步长自适应
float calcStep(float currentLuma, float targetLuma) {
float diff = abs(currentLuma - targetLuma);
if (diff > 2.0f) {
return 2.0f; // 粗调
} else if (diff > 0.5f) {
return 0.8f; // 细调
} else {
return 0.15f; // 锁定
}
}
你想想看，如果diff只有0.3档，你还用2档步长，那画面肯定来回晃。步长必须跟误差成正比。
4.2 防抖策略：稳住，别晃
AE防抖，不是OIS那种物理防抖。它防的是亮度抖动——明明场景没变，亮度却在跳。原因很多：传感器噪声、场景微小变化、算法本身的不稳定性。
我习惯把防抖分成两层：
- 帧间滤波：对亮度统计值做低通滤波，抑制高频噪声
- 决策滞后：亮度变化超过阈值才触发调整，避免微变响应
我的经验：帧间滤波用一阶IIR就够了，系数α取0.3~0.5。α太大收敛慢，α太小防抖效果差。我曾经试过α=0.1，结果画面像果冻一样抖了3秒才稳住。
4.2.1 滞后阈值设计
滞后阈值，就是“亮度变多少我才动”。我一般设两个阈值：
| 阈值类型 | 典型值 | 作用 |
|---|---|---|
| 变化触发阈值 | 0.3档 | 超过此值才启动AE调整 |
| 稳定退出阈值 | 0.1档 | 连续5帧低于此值，认为稳定 |
为什么要两个阈值？因为触发和退出不能一样。如果都是0.3档，那亮度在0.3档附近来回跳时，AE会反复开关，反而更抖。这叫“迟滞效应”，在控制理论里很常见。
4.3 Flicker抑制：跟频闪说再见
Flicker，就是灯光频闪。50Hz的灯光，在60fps下拍，画面会明暗交替。用户看着像“呼吸”，非常难受。
Flicker抑制的核心思路就一个：让曝光时间跟灯光周期对齐。
注意：Flicker抑制不是万能的。如果场景里同时有50Hz和60Hz的灯光，或者灯光本身就不稳定，那抑制效果会大打折扣。我曾经在演唱会现场翻过车——舞台灯光全是调光器控制的，频率乱跳，Flicker抑制完全失效。
4.3.1 曝光时间对齐策略
对于50Hz灯光（周期20ms），曝光时间必须是10ms的整数倍（半周期对齐）。对于60Hz灯光（周期16.67ms），曝光时间必须是8.33ms的整数倍。
高通平台里，Flicker检测和抑制的流程大概是：
- 检测阶段：统计连续多帧的亮度变化，分析频谱，判断是否存在100Hz或120Hz的波动
- 锁定阶段：确认频闪频率，标记为50Hz或60Hz
- 抑制阶段：限制曝光时间只能取对齐值，比如10ms、20ms、30ms……
// 伪代码：曝光时间对齐
int alignExposureTime(int desiredTime, int flickerFreq) {
int basePeriod;
if (flickerFreq == 50) {
basePeriod = 10; // 半周期10ms
} else if (flickerFreq == 60) {
basePeriod = 8; // 半周期8.33ms，取整为8ms
} else {
return desiredTime; // 无频闪，不限制
}
// 对齐到最近的整数倍
int aligned = (desiredTime / basePeriod) * basePeriod;
// 保证曝光时间在合理范围内
if (aligned < minExposure) aligned = minExposure;
if (aligned > maxExposure) aligned = maxExposure;
return aligned;
}
这里有个坑：对齐后曝光时间可能跟目标亮度不匹配。比如目标亮度需要15ms曝光，但50Hz下只能选10ms或20ms。选10ms画面偏暗，选20ms画面偏亮。怎么办？
我的做法是：优先保证Flicker抑制，然后用增益补偿亮度。选10ms曝光，增益提1.5倍，亮度就回来了。但增益不能无限提，否则噪声爆炸。一般增益补偿上限是4倍。
4.4 三者的协同：一个完整的AE周期
收敛速度、防抖、Flicker抑制，不是三个独立模块。它们必须协同工作。我画了一张流程图，你看看就明白了。
你看这个流程，Flicker检测在最前面，因为它决定了曝光时间的可选范围。然后才是亮度统计和滤波，滤波后的数据才进入滞后判断。最后步长自适应根据滞后状态决定调整幅度。整个流程是个闭环，每帧都在跑。
调试建议：如果你发现画面亮度稳定但Flicker没抑制住，先检查曝光时间对齐是否正确。如果对齐了但还有Flicker，可能是灯光频率不在50/60Hz标准范围内。这时候只能退而求其次，用更长的曝光时间（比如40ms以上）来平均掉波动。
4.5 实战中的常见问题与解法
我整理了几个在项目中反复踩过的坑，你直接拿去用。
| 问题现象 | 根因 | 解决方案 |
|---|---|---|
| 场景切换时亮度过冲 | 粗调步长太大 | 限制单帧最大调整≤3档，增加帧间平滑 |
| 静止场景亮度抖动 | IIR滤波系数太小 | 增大α到0.4~0.5，或增加滞后阈值 |
| 灯光下画面闪烁 | 曝光时间未对齐 | 强制对齐到半周期整数倍，用增益补偿亮度 |
| 暗光下Flicker明显 | 增益过高放大了波动 | 限制最大增益≤4倍，优先增加曝光时间 |
| 快速移动时亮度滞后 | 滤波太强 | 检测到运动时降低滤波系数，或旁路滤波 |
曾经踩过的坑：有一次在商场里测试，灯光是LED调光器控制的，频率在48Hz~52Hz之间随机跳。我的Flicker检测锁定了50Hz，但实际灯光在跳，导致画面每隔几秒就闪一次。后来我加了“频率跟踪”机制——每帧都重新检测频率，如果变化超过1Hz就更新对齐值。虽然增加了计算量，但问题解决了。
4.6 小结
AE收敛与稳定性，说白了就是三个字：快、稳、准。快是收敛速度，稳是防抖，准是Flicker抑制。三者互相制约，你不可能同时做到极致。我的经验是：优先保证Flicker抑制，其次是稳定性，最后才是收敛速度。因为用户对闪烁最敏感，对亮度变化速度反而没那么挑剔。
嗯，这一章的内容就到这里。记住，AE调优没有银弹，每个场景都要单独调试。你手上的高通平台，工具链很完善，多抓log、多分析、多试错，慢慢就能找到感觉。