037、HDR sensor的三种实现路径——DOL/Staggered/Split-Pixel的时序/带宽/算力代价对比——从sensor选型到ISP融合策略的决策树
去年秋天在给某旗舰机型调HDR预览时，遇到一个诡异现象——暗部噪点像雪花一样在屏幕上跳动，但切到普通SDR模式就一切正常。当时sensor用的是SONY IMX758，DOL模式，两帧曝光比1:16。我第一反应是长帧曝光时间太长导致运动物体鬼影，但客户反馈的是静态场景也闪。后来抓了raw dump才发现，问题根本不在sensor端，而是ISP的HDR融合模块在短帧和长帧对齐时，因为DOL两帧之间存在时间差，暗部区域的噪声被当成有效信号做了加权平均。这个案例让我意识到，HDR sensor的选型从来不是看峰值动态范围那么简单，时序结构决定了你后续ISP要填多少坑。
先说DOL（Digital Overlap）——这是最老牌也最普及的方案。它的本质是连续曝光两帧或多帧，每帧曝光时间不同，然后通过数字域融合得到宽动态。听起来简单，但时序上有个致命伤：两帧之间有时间间隔，运动物体会在这段时间内位移，导致融合时出现鬼影。你可以在sensor端缩短两帧间隔，但代价是长帧曝光时间被压缩，动态范围收益下降。带宽方面，DOL需要把多帧完整数据全部送到ISP，假设两帧都是12bit raw，带宽直接翻倍。算力上，ISP要做运动补偿、去鬼影、权重融合，这些算法在移动平台上都是吃GPU或NPU的怪兽。我见过不少团队在DOL上栽跟头，就是没算清楚带宽预算——尤其是4K60fps HDR场景，MIPI接口的lane数不够，只能降帧率，用户感知到的就是取景器卡顿。
Staggered方案是DOL的改良版，核心思想是把两帧曝光在时间上错开，但通过sensor内部的rolling shutter控制，让长帧的曝光结束时间和短帧的曝光开始时间尽量靠近。这样做的直接好处是运动物体的时间差被压缩到最小，鬼影问题大幅缓解。但代价是什么？时序复杂度指数级上升。你需要精确控制每行曝光的起始和结束时刻，sensor的寄存器配置变得极其繁琐，而且不同sensor厂商的实现细节差异很大——有的支持行交错，有的只支持帧交错。带宽上，Staggered和DOL一样，多帧数据都要传，没有本质改善。算力上，因为鬼影少了，ISP可以省掉一部分运动补偿的算力，但代价是sensor端要额外做时序校准，这部分开销往往被低估。我调过一颗OmniVision的Staggered sensor，光是把曝光时序调对就花了三周，期间各种奇奇怪怪的横条纹问题，最后发现是PLL配置和行消隐时间不匹配导致的。
Split-Pixel是近两年高端sensor的宠儿，原理是在一个像素单元里放两个不同灵敏度的光电二极管，一个大像素负责长曝光，一个小像素负责短曝光，同时读出。这个方案在时序上几乎完美——两帧是同时曝光的，不存在时间差，鬼影问题从根源上消失。带宽呢？因为两个子像素的数据是打包在一个raw里输出的，实际传输量只比单帧多一点点，远低于DOL和Staggered的翻倍开销。算力上，ISP只需要做像素级解包和融合，不需要运动补偿，算力消耗是三种方案里最低的。听起来完美对吧？但天下没有免费的午餐。Split-Pixel的代价在sensor成本——像素面积被一分为二，填充率下降，低照度下的灵敏度会受影响。而且，两个子像素之间的串扰和工艺偏差会导致固定模式噪声，需要额外的校准流程。我见过某颗三星的Split-Pixel sensor，在低增益下两子像素的响应差异能达到3%以上，如果不做逐像素校准，暗部会出现明显的网格状伪影。
现在把三种方案放在一起看，决策树的第一层是应用场景。如果是运动场景多——比如行车记录仪、运动相机——Split-Pixel是首选，鬼影问题直接绕开。如果是静态场景为主——比如安防监控、工业检测——DOL的性价比最高，sensor便宜，算法成熟，虽然鬼影存在但可以通过场景检测规避。Staggered则是个折中，适合那些既要一定运动鲁棒性又不想为Split-Pixel多花钱的项目。
决策树的第二层是系统带宽预算。这里有个容易被忽略的坑：HDR融合后的数据位宽。DOL和Staggered输出两帧12bit raw，融合后可能需要14bit或16bit中间格式，这会进一步推高ISP内部带宽。Split-Pixel虽然传输量小，但解包后的数据格式是特殊的，有些ISP的DMA设计不支持这种打包格式，需要额外的硬件转换模块。我建议在选型阶段就拉一个完整的带宽计算表，从sensor输出到ISP内部各模块，再到内存带宽，逐项核对。
第三层是算力分配。如果你的平台有强大的NPU，DOL的鬼影消除算法可以跑得很流畅，那DOL完全够用。如果算力紧张，Split-Pixel能省下大量运动补偿的算力，但要注意sensor校准的额外开销。我见过一个项目，为了省算力选了Split-Pixel，结果发现sensor的校准算法比鬼影消除还吃算力，最后得不偿失。
回到文章开头的那个IMX758问题。当时我查了sensor手册，发现DOL模式下长帧和短帧的读出时间差是固定的，但ISP的HDR融合模块默认假设两帧是严格对齐的。解决方案是在ISP里加一个帧间偏移补偿，根据sensor的时序参数动态调整融合权重。这个补丁打上去之后，暗部噪点问题立刻消失。但这件事给我的教训是：选HDR sensor时，不能只看动态范围数字，一定要拿到sensor的完整时序图，和ISP的融合算法做联合仿真。
最后给几条个人经验。第一，别迷信sensor厂商的HDR demo，他们用的都是自家ISP，和你的平台完全是两回事。第二，HDR调优一定要从raw域开始，别在YUV域瞎折腾，否则问题会被层层掩盖。第三，如果项目周期紧，优先选Split-Pixel，虽然sensor贵一点，但能省下大量调试时间——时间成本往往比物料成本更致命。第四，永远留一个HDR bypass的调试开关，方便定位问题出在sensor还是ISP。第五，多准备几组不同曝光比的测试场景，尤其是室内混合光源和逆光人像，这两个场景最能暴露HDR方案的短板。
做影像调试这行，没有银弹，只有取舍。HDR sensor的三种路径，本质上是在时间、带宽、算力、成本之间做权衡。你选的不是一颗sensor，而是一整套系统级的妥协方案。希望这篇笔记能帮你在选型时少走一些弯路。
