4、稳定性问题剖析：闪烁与抖动、局部极值陷阱、不同场景下的鲁棒性需求

各位好，我是老张。今天咱们聊聊自动曝光算法里最让人头疼的问题——稳定性。

说实话，收敛速度慢一点，用户可能只是觉得画面切换有点迟钝。但要是画面闪起来、抖起来，那体验感直接归零。我当年做安防摄像头的时候，就吃过这个亏。

4.1 闪烁与抖动：画面“呼吸”的根源

闪烁和抖动，说白了就是曝光值在目标附近来回震荡，停不下来。你想想看，画面一会儿亮一会儿暗，像不像在“呼吸”？用户看着肯定头晕。

为什么会这样？ 核心原因有两个：

• 步长过大：每次调整的幅度太猛，直接跨过了目标值，然后又在另一边跨回来，形成来回震荡。
• 反馈延迟：从调整曝光参数到画面亮度真正变化，中间有延迟。算法还没等到反馈，又发了一次调整指令，结果就过冲了。

我在项目中遇到过一种情况：在低光照场景下，传感器增益的响应曲线是非线性的。算法按线性模型去算步长，结果每一步都踩空，画面抖得跟筛子似的。

4.1.1 步长自适应策略

怎么解决？我建议用步长自适应。别死板地固定一个步长，要根据当前亮度与目标亮度的差值动态调整。

// 伪代码：步长自适应
float step = base_step;
float error = abs(current_luminance - target_luminance);

if (error > LARGE_THRESHOLD) {
    step = base_step * 2.0;  // 远距离，大步快跑
} else if (error > SMALL_THRESHOLD) {
    step = base_step;        // 中距离，正常步长
} else {
    step = base_step * 0.3;  // 近距离，小步微调
}

嗯，这里要注意：大步快跑的时候，要加一个限幅器，防止一步跨过头。我曾经因为没加限幅，结果画面从暗到亮直接“闪瞎”了测试同事的眼睛。

4.1.2 帧间平滑与去抖

除了步长，帧间平滑也是个好办法。别让曝光值突变，给它加个“阻尼”。

• 指数移动平均（EMA）：当前帧的曝光值 = α × 当前帧计算值 + (1-α) × 上一帧曝光值。α 越小，越平滑，但响应也越慢。
• 中值滤波：取最近 N 帧的曝光值的中位数。能有效去除单帧的异常跳变。

4.2 局部极值陷阱：算法“卡住”了

局部极值，是另一个大坑。算法以为找到了最优曝光值，其实只是在一个“小山包”上，真正的“山顶”在别处。

为什么会陷入局部极值？因为自动曝光算法通常只考虑当前帧的亮度信息，没有全局视野。比如，画面里有一块很亮的区域，算法可能就把曝光值调得很低，结果暗部细节全丢了。它觉得“平均亮度达标了”，其实画面质量很差。

我举个例子： 一个监控场景，白天阳光从窗户照进来，窗边很亮，室内很暗。算法如果只盯着平均亮度，很可能就把曝光值压在中间，结果窗外过曝，室内欠曝。这就是典型的局部极值。

4.2.1 跳出局部极值的方法

怎么跳出局部极值？我常用的方法有几种：

1. 多尺度搜索：先在大范围内粗搜，找到几个候选区域，再在候选区域里细搜。有点像“先看地图，再找街道”。
2. 随机扰动：每隔一段时间，给曝光值加一个小的随机扰动。如果扰动后画面质量变好，就继续往那个方向走。
3. 历史回溯：记录最近几次的曝光值和对应的画面质量。如果发现当前值比历史值差，就回退到历史最优值。

方法	优点	缺点	适用场景
多尺度搜索	全局性好，不易陷入局部极值	计算量大，收敛慢	场景变化缓慢，对实时性要求不高
随机扰动	实现简单，能跳出小范围陷阱	可能引起画面抖动	场景变化较快，需要快速响应
历史回溯	稳定可靠，不会越调越差	需要额外存储空间	对稳定性要求极高的场景

4.3 不同场景下的鲁棒性需求

自动曝光算法不是“一招鲜吃遍天”的。不同的场景，对稳定性的要求完全不同。

我总结了几类典型场景：

• 安防监控：要求 7×24 小时稳定运行，不能有闪烁。场景变化慢，但光照条件复杂（逆光、强光、夜间）。鲁棒性要求极高。
• 手机拍照：用户按下快门的一瞬间，要快速收敛到最佳曝光。允许短暂的抖动，但最终结果必须稳定。对速度要求高。
• 车载摄像头：场景变化极快（进出隧道、强光对向车灯）。要求极快的响应速度，同时不能有闪烁干扰驾驶员。
• 工业检测：光照条件可控，但要求极高的精度。曝光值必须稳定在 ±0.1% 以内。

4.3.1 场景自适应切换

我建议的做法是：设计一个场景分类器，根据当前画面的特征（平均亮度、亮度方差、直方图分布等），自动切换到不同的曝光策略。

// 伪代码：场景自适应曝光
SceneType detectScene(LuminanceStats stats) {
    if (stats.variance < LOW_VARIANCE) {
        return UNIFORM_LIGHT;  // 均匀光照
    } else if (stats.mean > HIGH_MEAN) {
        return BACKLIGHT;      // 逆光
    } else if (stats.mean < LOW_MEAN) {
        return LOW_LIGHT;      // 低光照
    } else {
        return NORMAL;
    }
}

void autoExposure(SceneType scene) {
    switch (scene) {
        case UNIFORM_LIGHT:
            // 快速收敛，小步长
            break;
        case BACKLIGHT:
            // 启用局部极值检测，多尺度搜索
            break;
        case LOW_LIGHT:
            // 启用帧间平滑，防止闪烁
            break;
        default:
            // 默认策略
            break;
    }
}

嗯，这里要注意：场景分类器本身也要稳定，不能频繁切换。我见过一个方案，场景分类器在“逆光”和“正常”之间来回跳，结果曝光策略也跟着来回跳，画面反而更不稳定了。

4.4 稳定性问题的知识体系

我把这一章的核心逻辑画成了一张图，方便你理解。

这张图把稳定性问题的三个分支和对应的解决方案串起来了。你可以把它当作一个检查清单，遇到问题时，对照着排查。