134、洞察驱动的实战标题——HDR融合的"对齐精度"——手持夜景模糊的根因往往是运动估计而非融合算法，从光流场到网格形变的实战昨晚凌晨两点，我在实验室盯着那台工程机里导出的RAW序列，第37次按下快门。取景器里是同一盏路灯下的水泥墙，手持，1/15秒，三帧包围曝光。回放时，墙上的砖缝边缘出现了一层淡淡的、像水彩晕染的鬼影。不是那种明显的重影，是那种让你怀疑自己是不是老花眼了的、均匀的模糊。当时我脑子里第一反应是融合权重没调好，或者拉普拉斯金字塔的层数不对。但当我单独把三帧的亮度对齐到中间帧，用棋盘格逐块比对时，发现暗部帧和亮部帧在砖缝位置有大约1.2像素的偏移——这个偏移量在单帧看几乎不可察觉，但在多尺度融合的细节层里，会被放大成可见的柔焦感。这就是典型的“对齐精度”问题，而且它藏在运动估计环节，不是融合环节。很多工程师遇到手持夜景模糊，第一反应是去调融合算法里的对比度阈值、饱和度保护、或者去试不同的去鬼影权重图。这些参数确实会影响最终观感，但如果你喂给融合模块的输入图像本身就没对齐到亚像素级，后面所有花哨的操作都是在给一个歪了的地基刷漆。我见过太多团队在融合算法上堆算力，光流用上了、深度学习去鬼影也上了，但最后效果还是糊。问题出在哪？出在运动估计的输入——他们用的是降采样后的图像做光流，或者用了过于平滑的正则项把真实的微小位移给抹掉了。手持夜景的难点在于，你面对的不是大位移的物体运动，而是整幅图像因为手抖产生的、空间非均匀的、幅度在0.5到3像素之间的微小形变。这种形变，光流场算出来往往是一片噪声，因为纹理弱的区域（比如天空、墙面）信噪比太低，光流算法会把噪声当成运动。我踩过最深的坑是直接用OpenCV的calcOpticalFlowFarneba
