037、HDR sensor的三种实现路径——DOL/Staggered/Split-Pixel的时序/带宽/算力代价对比——从sensor选型到ISP融合策略的决策树去年秋天在给某旗舰机型调HDR预览时遇到一个诡异现象——暗部噪点像雪花一样在屏幕上跳动但切到普通SDR模式就一切正常。当时sensor用的是SONY IMX758DOL模式两帧曝光比1:16。我第一反应是长帧曝光时间太长导致运动物体鬼影但客户反馈的是静态场景也闪。后来抓了raw dump才发现问题根本不在sensor端而是ISP的HDR融合模块在短帧和长帧对齐时因为DOL两帧之间存在时间差暗部区域的噪声被当成有效信号做了加权平均。这个案例让我意识到HDR sensor的选型从来不是看峰值动态范围那么简单时序结构决定了你后续ISP要填多少坑。先说DOLDigital 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内部各模块再到内存带宽逐项核对。第三层是算力分配。如果你的平台有强大的NPUDOL的鬼影消除算法可以跑得很流畅那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而是一整套系统级的妥协方案。希望这篇笔记能帮你在选型时少走一些弯路。 037、HDR sensor的三种实现路径——DOL/Staggered/Split-Pixel的时序/带宽/算力代价对比——从sensor选型到ISP融合策略的决策树
037、HDR sensor的三种实现路径——DOL/Staggered/Split-Pixel的时序/带宽/算力代价对比——从sensor选型到ISP融合策略的决策树去年秋天在给某旗舰机型调HDR预览时遇到一个诡异现象——暗部噪点像雪花一样在屏幕上跳动但切到普通SDR模式就一切正常。当时sensor用的是SONY IMX758DOL模式两帧曝光比1:16。我第一反应是长帧曝光时间太长导致运动物体鬼影但客户反馈的是静态场景也闪。后来抓了raw dump才发现问题根本不在sensor端而是ISP的HDR融合模块在短帧和长帧对齐时因为DOL两帧之间存在时间差暗部区域的噪声被当成有效信号做了加权平均。这个案例让我意识到HDR sensor的选型从来不是看峰值动态范围那么简单时序结构决定了你后续ISP要填多少坑。先说DOLDigital 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内部各模块再到内存带宽逐项核对。第三层是算力分配。如果你的平台有强大的NPUDOL的鬼影消除算法可以跑得很流畅那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而是一整套系统级的妥协方案。希望这篇笔记能帮你在选型时少走一些弯路。