132、洞察驱动的实战标题——时域降噪的“鬼影博弈“——运动检测阈值高一点还是低一点？从运动矢量置信度到混合权重的工程调优
132、洞察驱动的实战标题——时域降噪的"鬼影博弈"——运动检测阈值高一点还是低一点？从运动矢量置信度到混合权重的工程调优
昨晚凌晨两点，还在盯着示波器上那几帧鬼影发呆。客户反馈说夜间行车记录仪在等红灯时，旁边车道一辆白色轿车驶过，车尾拖出一道半透明的残影，像极了老电影里的重影特效。这不是算法失效，恰恰相反，是时域降噪在“过度工作”——它把不该融合的帧给融合了。
时域降噪的本质是赌徒游戏：赌当前像素和参考帧里的对应像素是同一个物体，赌赢了信噪比提升，赌输了就留下鬼影。而运动检测阈值，就是这个赌徒的胆量参数。调高了，它变得保守，鬼影少了但噪声也压不住；调低了，它变得激进，噪声干净了但鬼影频出。这个平衡点，从来不是固定值，而是随场景、亮度、传感器增益动态漂移的。
问题现场：那台“会分身”的行车记录仪
先还原一下当时的调试环境。IMX662传感器，1080p@30fps，三帧时域降噪加两帧空域降噪串联。客户反馈的鬼影出现在夜间城市道路，路灯照明，车速约40km/h，旁边车道车辆相对速度约15km/h。我们用串口抓了降噪前后的RAW数据，发现鬼影区域的像素值比真实车身边缘高出约12%——这不是简单的边缘拖尾，而是整块车身区域被“半融合”了。
第一反应是运动检测阈值设低了。查了代码，当前阈值是全局固定值，基于像素亮度差和梯度差加权计算，阈值设定为12（8bit数据）。夜间场景噪声水平大约在6-8个灰度级，理论上12的阈值应该能区分噪声和真实运动。但问题出在“运动”的定义上——我们用的是像素级运动检测，没有考虑运动矢量的空间一致性。