2、场景适配概述：场景分类与检测引擎
各位同学，今天我们来聊聊场景适配。说白了，就是让手机摄像头知道它现在在拍什么，然后自动把参数调到最合适的档位。
我刚开始做Camera HAL的时候，觉得这玩意儿不就是几个if-else嘛。后来踩了坑才发现——场景适配是整个ISP管线的指挥棒，指挥错了，后面算法再牛也白搭。
2.1 四大核心场景分类
手机摄影的场景千变万化，但从算法适配的角度，我们通常归为四类。这四类基本覆盖了用户90%以上的拍照场景。
| 场景类型 | 核心挑战 | 典型触发条件 | ISP处理重点 |
|---|---|---|---|
| 夜景 | 低照度、信噪比差 | Lux ≤ 50 | 多帧降噪、长曝光、增益控制 |
| HDR | 高动态范围、过曝/欠曝 | 场景动态范围 > 12EV | 多帧融合、局部色调映射 |
| 人像 | 肤色还原、背景虚化 | 人脸检测置信度 > 0.8 | 肤色保护、景深计算、美颜 |
| 运动 | 运动模糊、对焦延迟 | 帧间运动矢量 > 阈值 | 短曝光、追焦、电子防抖 |
关键认知：场景不是互斥的。比如夜景下拍人像，或者运动场景遇到逆光——这时候场景检测引擎需要做优先级仲裁。我个人习惯把「人像」优先级提到最高，因为肤色一旦翻车，用户直接差评。
2.2 场景检测引擎架构
场景检测引擎，说白了就是一套从传感器数据到场景标签的流水线。我参与过的项目里，引擎通常分三层：
- 物理层采集——从Sensor、Gyro、Lux Sensor拿原始数据
- 特征提取层——计算亮度直方图、运动矢量、人脸框等
- 决策融合层——用规则引擎或轻量模型输出最终场景标签
下面这张图是我自己画的一个简化架构，大家感受一下数据流：
2.3 各场景的检测特征与阈值
每个场景都有自己敏感的特征维度。我整理了一份常用特征表，大家在写场景检测逻辑时可以直接参考：
| 场景 | 关键特征 | 典型阈值 | 避坑点 |
|---|---|---|---|
| 夜景 | 平均亮度、暗部占比 | Y_avg < 40, 暗部像素 > 60% | 避免把「暗光HDR」误判为夜景 |
| HDR | 亮度直方图双峰、过曝/欠曝比例 | 过曝像素 > 5% 且 欠曝像素 > 5% | 逆光人像要优先走人像流程 |
| 人像 | 人脸数量、人脸大小、人脸置信度 | 人脸框面积 > 5% 画面 | 侧脸/戴墨镜时置信度会掉 |
| 运动 | 帧间SAD、陀螺仪角速度 | SAD > 15% 或 Gyro > 0.5 rad/s | 手持微抖不算运动，要加高通滤波 |
我曾经踩过的坑：有一版场景检测把「夜景」和「HDR」的触发条件写成了互斥逻辑。结果用户在夜景下拍灯牌，灯牌过曝了但引擎死活不肯切HDR，因为夜景优先级更高。后来我改成「场景标签可以叠加，由ISP各模块各自决定是否响应」——这才解决问题。
2.4 场景检测的工程实现要点
理论说完了，咱们聊聊落地。场景检测引擎在手机上是跑在实时管线里的，每一帧只有几毫秒的处理时间。这里有几个工程要点：
- 特征计算要轻量——别在每一帧做全图CNN，用直方图和统计量就够了。我见过一个方案用MobileNet做场景分类，结果帧率直接掉到15fps。
- 时间窗口平滑——场景标签不能一帧一变。通常维护一个5~10帧的滑动窗口，取众数作为最终标签。
- 优先级仲裁——当多个场景同时触发时，按人像 > 运动 > HDR > 夜景 的优先级裁决。为什么人像最高？因为用户拍人时对肤色最敏感。
- 反馈机制——场景标签可以反向影响Sensor的曝光策略。比如检测到运动场景，可以主动提高Sensor的增益来缩短曝光时间。
一个小技巧：在调试阶段，把场景检测的中间结果（亮度直方图、运动矢量、人脸框）全部dump到log里。这样现场复现问题时，一眼就能看出是特征提取错了还是决策逻辑错了。我团队现在每个项目都保留这个调试开关。
2.5 场景适配的最终目标
说了这么多，场景适配到底要达成什么效果？我个人理解就一句话：让用户无感地获得最佳画质。
用户不会关心你用的是多帧融合还是单帧HDR，他只关心——拍夜景够亮不糊，拍逆光人脸不黑，拍运动主体清晰。场景检测引擎就是那个在背后默默干活的人。