037、人脸AE与场景识别：基于人脸检测的曝光补偿与背光场景优化
037、人脸AE与场景识别：基于人脸检测的曝光补偿与背光场景优化
一、一个让我加班到凌晨三点的bug
2019年某款旗舰机的前摄调试，我至今记忆犹新。用户反馈在逆光自拍时，人脸要么过曝成“白板”，要么欠曝成“黑炭”。我们当时的AE策略很简单：检测到人脸，就把人脸区域作为ROI做曝光权重。结果呢？实验室里一切正常，一到真实场景就翻车。
后来抓了上百组log才发现问题：当人脸处于强背光时，人脸区域的亮度可能只有背景的1/10，AE算法拼命提亮人脸，结果背景完全过曝，人脸虽然亮了但噪点爆炸，肤色失真。更坑的是，某些场景下人脸检测框抖动，导致AE在亮暗之间来回跳变，画面像在“呼吸”。
这个案例让我意识到：人脸AE不是简单的“检测到人脸就加权”这么简单，它需要一套完整的场景识别与曝光补偿策略。
二、人脸AE的核心矛盾：局部与全局的博弈
传统AE算法基于全局亮度统计，用直方图或平均亮度计算目标曝光。人脸AE引入后，问题变成了：如何在保证人脸曝光准确的同时，不破坏整体画面的观感？
这里有个关键参数——人脸曝光权重。权重设高了，人脸准了但背景崩了；权重设低了，人脸又拉不回来。我见过不少工程师直接给100%权重，结果就是上面说的翻车现场。
实际调试中，我通常把权重控制在30%-70%之间，具体取决于场景。但光有权重不够，你得先判断当前是什么场景。
三、场景识别：背光、顺光、侧光与混合光
人脸AE的第一步不是调曝光，而是识别光照场景。我常用的判断逻辑：
// 场景判断伪代码 - 别直接复制，要根据sensor特性调阈值intdetect_light_scene(face_roi*roi,frame_stats*stats){floatface_luma=get_face_avg_luma(roi);// 人脸平均亮度floatbg_luma=get_bg_avg_luma(stats,roi);// 背景平均亮度（排除人脸区域）floatface_bg_ratio=face_luma/(bg_luma+0.01);// 这里加0.01防除零，踩过坑的都知道if(face_bg_ratio<0.3){// 背光场景：人脸亮度远低于背景// 这里踩过坑：0.3这个阈值在暗光下要调低，否则误判returnSCENE_BACKLIGHT;}elseif(face_bg_ratio>2.0){// 顺光场景：人脸比背景亮，比如舞台聚光灯returnSCENE_FRONTLIGHT;}else{// 正常或侧光场景returnSCENE_NORMAL;}}这个判断看似简单，实际坑很多。比如当人脸和背景都在暗光下时，face_bg_ratio可能接近1.0，但实际是暗光场景而非正常场景。所以我会再加一个全局亮度判断：
if(stats->global_luma<30&&face_bg_ratio>0.5){// 全局暗光，不要误判为正常场景returnSCENE_LOWLIGHT;}四、背光场景的曝光补偿策略
背光是人脸AE最头疼的场景。我的策略分三步走：
第一步：强制提升人脸亮度，但设定上限
不要试图把人脸拉到18%灰（标准中性灰），背光下强行拉亮会导致噪点爆炸。我一般设定目标亮度为正常场景的70%-80%。比如正常场景人脸目标亮度是120（0-255范围），背光下设为90-100就够了。
第二步：动态调整曝光时间与增益的配比
背光场景通常需要更长曝光时间或更高增益。这里有个取舍：曝光时间长了，人脸会糊（尤其是小孩或运动场景）；增益高了，噪点多。我常用的策略是：先拉曝光时间到安全上限（比如1/30s），如果还不够，再拉增益。
// 背光场景曝光参数计算 - 注释写清楚，免得后来人看不懂voidcalc_backlight_exposure(face_info*face,ae_params*params){floattarget_luma=90;// 背光目标亮度，比正常低floatcurrent_luma=face->avg_luma;floatgain_ratio=target_luma/(current_luma+0.01);// 限制最大增益倍数，别这样写死，要根据sensor能力来constfloatMAX_GAIN=4.0;if(gain_ratio>MAX_GAIN){// 增益不够，拉曝光时间params->exposure_time*=(gain_ratio/MAX_GAIN);params->gain=MAX_GAIN;}else{params->gain*=gain_ratio;}// 这里踩过坑：曝光时间不能超过帧率的限制，否则掉帧if(params->exposure_time>MAX_EXPOSURE_TIME){params->exposure_time=MAX_EXPOSURE_TIME;// 提示：这种情况下只能接受人脸欠曝，或者开启HDR}}第三步：引入局部对比度增强
单纯调曝光不够，背光下的人脸即使亮度拉上去了，对比度也偏低，看起来“灰蒙蒙”的。我通常在ISP的gamma或LTM（局部色调映射）模块做手脚：在人脸区域提升对比度，背景区域压低对比度避免过曝。
五、人脸检测框抖动问题
这是另一个让人抓狂的问题。人脸检测框在帧与帧之间抖动，导致AE参数也跟着抖。解决方案：
方案一：时间域滤波
对检测框坐标做低通滤波，比如用一阶IIR：
// 人脸框平滑 - 别用太强的滤波，否则跟踪延迟staticface_rect smooth_rect={0};floatalpha=0.3;// 平滑系数，越大越平滑但延迟越大smooth_rect.x=alpha*smooth_rect.x+(1-alpha)*current_rect.x;smooth_rect.y=alpha*smooth_rect.y+(1-alpha)*current_rect.y;smooth_rect.w=alpha*smooth_rect.w+(1-alpha)*current_rect.w;smooth_rect.h=alpha*smooth_rect.h+(1-alpha)*current_rect.h;方案二：扩大ROI区域
不要只用人脸框作为ROI，而是向外扩展20%-30%。这样即使检测框抖动，ROI内的亮度统计也相对稳定。
方案三：锁定曝光参数
当检测到人脸且场景稳定时，锁定AE参数一段时间（比如0.5秒），避免频繁调整。这个策略在视频录制中尤其重要。
六、多张人脸场景的处理
自拍杆合影、多人会议场景，多张人脸同时出现。策略很简单：取所有人脸亮度的加权平均，权重可以按人脸大小或置信度分配。
但有个特殊情况：如果一张脸在背光，另一张在顺光，怎么办？我倾向于优先照顾背光的那张脸，因为顺光那张本身已经够亮了，再亮也不会太差。但如果两张脸亮度差异超过3档，那就只能取舍了——这时候可以提示用户“请调整位置”。
七、与HDR的联动
背光场景的最佳搭档是HDR。当检测到背光且人脸与背景亮度差超过一定阈值时，自动开启HDR模式。
HDR的曝光策略也要调整：短帧曝光用于背景，长帧曝光用于人脸。具体来说，短帧的曝光时间按背景亮度计算，长帧的曝光时间按人脸亮度计算。这样合成后的画面，人脸和背景都能看清。
// HDR模式下的人脸AE - 这里踩过坑，别把长短帧搞反了voidcalc_hdr_exposure_for_face(face_info*face,frame_stats*stats){// 短帧：保证背景不过曝floatshort_target=180;// 背景目标亮度，稍微欠曝一点保留细节floatshort_gain=short_target/(stats->bg_luma+0.01);// 长帧：保证人脸够亮floatlong_target=100;// 人脸目标亮度floatlong_gain=long_target/(face->avg_luma+0.01);// 限制长短帧的曝光比，别这样写死，要根据HDR能力来constfloatMAX_HDR_RATIO=16.0;if(long_gain/short_gain>MAX_HDR_RATIO){// 差异太大，HDR也救不了，需要补光// 提示：可以开启屏幕补光或闪光灯}}八、实战经验总结
不要迷信人脸检测：检测到人脸不等于AE就解决了。人脸检测的置信度、大小、位置都要纳入考量。比如一张侧脸或部分遮挡的脸，权重应该降低。
场景切换要平滑：从背光场景切换到顺光场景，曝光参数不要突变。我一般用3-5帧做渐变过渡，避免画面闪烁。
预留手动调节空间：自动曝光再智能，也架不住用户有特殊需求。在相机APP中保留曝光补偿滑块，让用户可以±2档调节。
不同sensor差异巨大：同样的算法在IMX586上跑得好，换到OV64B可能就翻车。因为不同sensor的动态范围、噪声特性、响应曲线都不一样。每次换sensor都要重新标定参数。
测试场景要覆盖全：室内背光（窗户前）、室外逆光（夕阳下）、混合光源（舞台灯光+环境光）、暗光背光（夜晚路灯下）……每个场景都要实测，别只依赖实验室的灯箱。
log要打全：调试阶段，把场景判断结果、人脸亮度、背景亮度、最终曝光参数都打出来。我习惯用“TAG_FACE_AE”作为log标签，方便过滤。没有log，出了问题只能靠猜。
最后说一句：人脸AE没有银弹。每个场景、每颗sensor、每款镜头都有自己的脾气。调试的本质是理解这些脾气的规律，然后找到那个“够用”的平衡点。别追求完美，追求“用户不骂娘”就够了。