050、HDR融合的对齐精度——手持夜景模糊的根因往往是运动估计而非融合算法——从全局运动估计到局部光流的对齐策略与算力预算
050、HDR融合的对齐精度——手持夜景模糊的根因往往是运动估计而非融合算法——从全局运动估计到局部光流的对齐策略与算力预算
凌晨两点，实验室的灯还亮着。面前这台工程机的取景器里，夜景样张的楼宇边缘泛着一层诡异的“鬼影”——不是那种明显的重影，而是像水彩洇开一样的半透明拖尾。隔壁工位的兄弟已经换了三版融合权重，把金字塔分解的层数从四层调到六层，甚至试了基于频域的拉普拉斯融合，鬼影纹丝不动。他扭头看我：“是不是融合核函数选错了？”
我盯着屏幕看了十秒，让他把运动估计的中间结果dump出来。果然，全局单应性矩阵算出来的位移向量，在画面右下角区域跟实际像素偏移差了将近三个像素。问题根本不在融合，在对齐。这个场景我太熟了——手持夜景，暗光下信噪比低，特征点提取本身就抖，再加上场景里有近景的栏杆和远景的塔楼，单一全局模型根本描述不了这种视差。融合算法再精巧，喂进去的对齐数据是错的，输出必然是糊的。
先别急着上光流，全局运动估计的坑你踩全了吗
很多工程师一听到“手持夜景模糊”，第一反应就是“上光流”。光流确实能处理局部运动，但光流是吃算力的大户，而且在小光圈、长曝光的夜景场景里，光流本身的可靠性也存疑——纹理稀疏的区域，光流估计出来的向量基本是噪声。我见过有人直接在1080p分辨率上跑稠密光流，一帧耗时八十毫秒，功耗直接顶到发热降频，最后效果还不如老老实实把全局对齐做好。
全局运动估计的坑，第一个是特征点提取的鲁棒性。夜景图像信噪比低，ORB或者FAST角点在暗部区域提取出来的点，很多是噪声响应，不是真实角点。这里有个土办法，但很管用：先做一次轻量的双边滤波或者引导滤波，把噪声压一压，再提特征点。别小看这一步，它能让你后续的RANSAC迭代次数少一半。第二个坑是RANSAC的阈值设置。默认阈值往往是针对白天场景调的，夜景下特征点本身的定位误差就大，阈值设得太死，内点率会低得离谱，最后拟合出来的单应性矩阵被少数外点带偏。我习惯把阈值放宽到1.5到2个像素，同时把迭代次数上限提高，算力代价不大，但稳定性提升明显。
第三个坑，也是我最想强调的——全局运动模型的选择。很多人默认用单应性矩阵（Homography），但手持夜景的抖动，除了平移和旋转，还有绕光心的微小旋转带来的透视变化，以及更麻烦的——场景本身的视差。如果画面里同时有近景和远景，单应性矩阵根本描述不了这种深度不连续造成的位移差异。这时候有两个选择：一是用仿射模型加残差补偿，二是直接上分块运动估计。我的经验是，先跑一次全局单应性，把对齐后的残差图算出来，如果残差在某个区域明显大于其他区域，那就说明那个区域需要局部处理，而不是全局换模型。
局部光流不是万能药，算力预算才是真正的决策者
当全局对齐的残差图告诉你“这里有局部运动”时，你面临一个选择：是上稠密光流，还是上稀疏光流加插值，还是用分块仿射？这个决策的根源不是算法精度，而是你的算力预算。
以手机平台为例，一个典型的夜景HDR流程，留给运动估计的算力预算大概在五到十毫秒（以中端SoC的NPU或DSP算力折算）。稠密光流（比如Farneback或者PWC-Net的轻量版）在720p分辨率下，纯CPU跑基本要二十毫秒以上，直接超预算。这时候我通常的做法是：全局单应性打底，然后只在残差大的区域跑稀疏光流（Lucas-Kanade金字塔），特征点用网格化采样保证分布均匀，最后用径向基函数插值把稀疏向量稠密化。这个流程在720p下能压到六毫秒左右，效果跟直接跑稠密光流差距不大，但算力消耗只有后者的三分之一。
这里有个容易犯的错——光流估计的迭代次数和金字塔层数，很多人喜欢往大了调，觉得越精细越好。实际上夜景场景纹理弱，金字塔层数太多，顶层图像太小，估计出来的向量基本是错的，还会把误差逐层放大。我一般金字塔三层封顶，每层迭代三次，再多就是浪费算力。另外，光流的窗口大小也要注意，夜景下运动幅度往往不大（手持抖动一般在一到两个像素），窗口设太大反而会把邻近区域的运动平滑掉，丢失细节。
还有一个细节，很多人忽略——光流估计的输入图像，一定要做降噪。夜景原图的噪声会让光流算法把噪声当成纹理来追踪，出来的向量场跟实际运动完全对不上。我习惯先做一次时域降噪（如果有三帧以上的输入）或者空间降噪（双边滤波），再做光流。这个预处理大概花一毫秒，但能省掉后面大量的调试时间。
对齐精度的验收标准，别只看主观效果
很多团队调试HDR对齐，验收标准就是“人眼看不出鬼影”。这个标准太主观了，而且容易掩盖问题。我建议用两个客观指标：一是对齐残差的均方根误差（RMSE），在融合前把参考帧和待融合帧的对齐结果做差，算一下残差；二是边缘区域的梯度一致性——鬼影最容易出现在高对比度边缘，所以专门统计边缘像素的对齐误差。这两个指标能帮你量化每次改动的影响，而不是靠肉眼反复对比。
但客观指标也不是万能的。有一次我调一个车载场景的HDR，残差RMSE降到了0.8个像素，但实际预览时，路牌边缘还是有一圈微弱的亮边。后来发现是融合权重在边缘区域分配不均——对齐是准的，但融合时把高亮帧的权重给大了，导致边缘过曝。所以对齐精度是必要不充分条件，融合策略还得配合着调。
算力预算的分配哲学：把好钢用在刀刃上
最后聊聊算力预算的分配。我见过太多团队把预算大头花在光流上，结果融合阶段只能用最朴素的加权平均。其实融合阶段的算力投入回报率更高——一个简单的拉普拉斯金字塔融合，配合基于对齐残差的权重图，就能显著改善鬼影和晕影。我的建议是：运动估计（全局+局部）占总预算的百分之五十到六十，融合占百分之三十，剩下的留给预处理和后期。
具体到运动估计内部，全局单应性只花百分之十的预算，剩下的都留给局部光流和插值。因为全局运动是基础，错了全盘皆输，但它的计算量不大；局部光流才是精度提升的关键，值得多花算力。另外，如果平台有硬件光流加速（很多中高端SoC都有），一定要用——硬件光流的速度是软件实现的五到十倍，而且功耗更低。但要注意，硬件光流的精度往往不如软件算法，所以我的策略是：硬件光流跑粗对齐，软件光流在关键区域做精修，两者配合。
经验之谈：调试HDR对齐，先建好可视化工具链
最后说点个人经验。调试HDR对齐，最忌讳的就是“盲调”——改一个参数，跑一版，肉眼看效果，不行再改。效率太低。我建议花两天时间搭一套可视化工具链：把特征点提取、全局单应性矩阵、光流向量场、对齐残差图、融合权重图全部可视化输出，叠加在原始帧上。这样每次改动，你一眼就能看出是哪个环节出了问题——是特征点提歪了，还是光流在某个区域失效了，还是融合权重分配不合理。这套工具链的投入，会在后续所有HDR相关项目里持续回报你。
还有一点，别迷信“最新算法”。PWC-Net、RAFT这些深度学习光流算法精度确实高，但部署到嵌入式平台，模型量化、推理框架适配、功耗控制，每一项都是大坑。在量产项目里，一个调好的传统光流算法，配合合理的算力分配，往往比一个没调好的深度学习模型更可靠。技术选型不是选最先进的，是选最可控的。
回到开头那个场景。我把他的运动估计从全局单应性换成“全局单应性+局部稀疏光流”的组合，残差RMSE从2.1像素降到0.6像素，鬼影肉眼不可见。融合算法一行没改。他愣了半天，说了一句：“原来瓶颈在这儿。”——对，瓶颈往往不在你盯着的那块地方。