124、洞察驱动的实战标题——HDR+的"对齐vs融合"——Google HDR+的对齐策略与暴力融合的差异，如何用多尺度光流实现亚像素对齐上周在调试一台国产旗舰机的夜景HDR时，我盯着屏幕上的鬼影看了整整三个小时。那是一个典型的动态场景——霓虹灯牌下有人走过，远处有车流。单帧曝光正常，但三帧合成后，人脸的边缘出现了半透明的重影，像极了PS里图层不透明度调错的样子。我第一反应是融合权重出了问题，调了半天曲线，鬼影纹丝不动。后来把中间帧和参考帧单独拉出来做差分，才发现问题根本不在融合，而在对齐——中间帧的位移量是2.3个像素，而我的对齐模块只做了整像素搜索。这个场景我太熟悉了。2018年我接手一个车载HDR项目时，同样的问题在隧道出入口反复出现。当时团队里有个刚从学校毕业的同事，坚持用全局仿射变换做对齐，理由是"车载场景相机固定，运动主要是平移"。结果在雨天，雨滴打在挡风玻璃上，每颗雨滴都是一个独立的运动矢量，全局模型直接崩了。后来我们换成了分块光流，鬼影少了，但计算量涨了四倍，ISP的DSP流水线差点被拖垮。Google HDR+的论文我读过不下十遍，每次读都有新体会。它最反直觉的地方在于——对齐和融合不是两个独立模块，而是一个联合优化问题。传统做法是"先对齐，再融合"，对齐误差直接传递到融合阶段。HDR+的做法是"对齐时考虑融合的容错性，融合时补偿对齐的残差"。这个思想差异，决定了最终成片质量的量级差距。先说说暴力融合为什么不行。所谓暴力融合，就是多帧直接加权平均，权重由曝光时间或亮度决定。在静态场景下，这招确实有效，信噪比提升明显。但一旦有运动物体，问题就来了——运动物体在不同帧里的位置不同，直接平均等于把物体"涂抹"在画面
124、洞察驱动的实战标题——HDR+的"对齐vs融合"——Google HDR+的对齐策略与暴力融合的差异，如何用多尺度光流实现亚像素对齐上周在调试一台国产旗舰机的夜景HDR时，我盯着屏幕上的鬼影看了整整三个小时。那是一个典型的动态场景——霓虹灯牌下有人走过，远处有车流。单帧曝光正常，但三帧合成后，人脸的边缘出现了半透明的重影，像极了PS里图层不透明度调错的样子。我第一反应是融合权重出了问题，调了半天曲线，鬼影纹丝不动。后来把中间帧和参考帧单独拉出来做差分，才发现问题根本不在融合，而在对齐——中间帧的位移量是2.3个像素，而我的对齐模块只做了整像素搜索。这个场景我太熟悉了。2018年我接手一个车载HDR项目时，同样的问题在隧道出入口反复出现。当时团队里有个刚从学校毕业的同事，坚持用全局仿射变换做对齐，理由是"车载场景相机固定，运动主要是平移"。结果在雨天，雨滴打在挡风玻璃上，每颗雨滴都是一个独立的运动矢量，全局模型直接崩了。后来我们换成了分块光流，鬼影少了，但计算量涨了四倍，ISP的DSP流水线差点被拖垮。Google HDR+的论文我读过不下十遍，每次读都有新体会。它最反直觉的地方在于——对齐和融合不是两个独立模块，而是一个联合优化问题。传统做法是"先对齐，再融合"，对齐误差直接传递到融合阶段。HDR+的做法是"对齐时考虑融合的容错性，融合时补偿对齐的残差"。这个思想差异，决定了最终成片质量的量级差距。先说说暴力融合为什么不行。所谓暴力融合，就是多帧直接加权平均，权重由曝光时间或亮度决定。在静态场景下，这招确实有效，信噪比提升明显。但一旦有运动物体，问题就来了——运动物体在不同帧里的位置不同，直接平均等于把物体"涂抹"在画面
文法与四元式：IF-ELSE翻译程序的核心实现)
