企业官网建设流程全解析

016、Sensor HDR 模式选型：DCG、Staggered HDR、QBC HDR 的原理与寄存器实现

一、从一次“暗部死黑”的调试说起

去年做某款旗舰机主摄调试，Sensor 是 Sony IMX766，默认开了 Staggered HDR。白天场景效果惊艳，高光不过曝，暗部细节丰富。但一到室内弱光（约 5 lux），预览画面暗部出现明显“死黑”，而且伴随横条纹噪声。我以为是 ISP 的 Tone Mapping 没调好，折腾了三天，改 Curve、调 Local Contrast，效果始终不理想。

后来用示波器抓了 Sensor 的 VSYNC 和 MIPI 数据线，发现 Staggered HDR 模式下，长曝光帧（Long Frame）的读出时间被压缩到了 1/30s 以内——因为要在一个帧周期内塞进 Long、Middle、Short 三帧。弱光下 Long Frame 的积分时间本来就不够，读出时又被压缩，导致信噪比崩了。最后换成了 DCG HDR，问题解决。

这个案例让我意识到：HDR 模式选型不是“哪个参数高就用哪个”，而是要根据场景、Sensor 物理特性、ISP 处理能力综合权衡。下面我把三种主流 Sensor HDR 模式的原理、寄存器实现和调试坑点写清楚。

二、DCG HDR：双转换增益，最“老实”的方案

原理一句话

DCG（Dual Conversion Gain）HDR 的核心是：同一个像素，在单帧曝光内，先以高转换增益（HCG）读出，再以低转换增益（LCG）读出。高增益对应暗部细节，低增益对应高光部分。ISP 拿到两路数据后，按像素级融合。

寄存器实现要点

DCG 模式通常需要配置两组寄存器：

// 以 Sony IMX586 为例（寄存器地址 0x0100 是模式选择） // 踩坑：必须先关流（0x0100=0x00）再改增益模式，否则 Sensor 会挂死 write_sensor_reg(0x0100, 0x00); // 关流，别偷懒 // 设置 DCG 模式：0x3000 寄存器 bit[3] 控制增益切换 // 别这样写：直接写 0x08，会覆盖其他 bit uint8_t val = read_sensor_reg(0x3000); val |= 0x08; // 只置位 DCG 使能位 write_sensor_reg(0x3000, val); // 配置 HCG 和 LCG 的增益值 // HCG 增益：0x3010，典型值 0x10（对应 16x 增益） // LCG 增益：0x3011，典型值 0x01（对应 1x 增益） write_sensor_reg(0x3010, 0x10); // 高增益，暗部靠它 write_sensor_reg(0x3011, 0x01); // 低增益，高光靠它 // 重新开流 write_sensor_reg(0x0100, 0x01);

调试坑点

1. 增益切换点：DCG 的 HCG 和 LCG 之间有一个“切换点”，即当入射光强达到某个阈值时，Sensor 内部自动从 HCG 切到 LCG。这个阈值由 Sensor 的物理设计决定，通常不可调。如果场景亮度刚好在切换点附近，会出现“亮度跳变”——画面突然变亮或变暗。解决办法是：在 ISP 端做帧间平滑，或者干脆避开这个亮度区间。

2. 读出噪声：DCG 模式下，HCG 的读出噪声通常比 LCG 高 2-3 倍。因为高增益放大了信号，也放大了噪声。弱光下如果 HCG 的积分时间不够，暗部反而比普通模式更差。我那次调试就是吃了这个亏。

3. 寄存器时序：有些 Sensor 要求 DCG 配置必须在 VBLANK 期间写入，否则会丢帧。建议在 VSYNC 中断里写，或者至少保证写入后等 2 帧再读数据。

三、Staggered HDR：时间交错，动态范围最大但代价也最大

原理一句话

Staggered HDR 在一个帧周期内，连续曝光三帧：Long（长曝光）、Middle（中曝光）、Short（短曝光）。三帧依次读出后，ISP 做运动补偿和融合。动态范围可以做到 120dB 以上。

寄存器实现要点

Staggered HDR 的寄存器配置比 DCG 复杂，核心是控制三帧的曝光时间和增益：

// 以 Samsung ISOCELL GN1 为例 // 先进入 Staggered 模式：0x0100=0x00，然后写 0x0A00 寄存器 write_sensor_reg(0x0100, 0x00); // 使能 Staggered HDR：0x0A00 bit[0]=1 write_sensor_reg(0x0A00, 0x01); // 配置三帧的曝光行数（单位：行） // 注意：Long 帧的行数不能超过 VTS（垂直总行数）的 60% // 踩坑：如果 Long 帧行数超过 VTS 的 70%，Middle 帧会被吃掉 write_sensor_reg(0x0A10, 0x1E0); // Long: 480 行 write_sensor_reg(0x0A11, 0x0F0); // Middle: 240 行 write_sensor_reg(0x0A12, 0x078); // Short: 120 行 // 配置三帧的增益 write_sensor_reg(0x0A20, 0x10); // Long 增益：16x write_sensor_reg(0x0A21, 0x04); // Middle 增益：4x write_sensor_reg(0x0A22, 0x01); // Short 增益：1x // 配置读出顺序：通常 Long 先读，Middle 次之，Short 最后 // 0x0A30 bit[1:0]：00=Long->Middle->Short，01=Short->Middle->Long write_sensor_reg(0x0A30, 0x00); write_sensor_reg(0x0100, 0x01);

调试坑点

1. 运动伪影：这是 Staggered HDR 最大的痛点。三帧在不同时间点曝光，如果画面中有运动物体（比如行人、汽车），融合后会出现“鬼影”。ISP 的运动补偿算法只能缓解，不能根除。我的经验是：如果场景中有快速运动，宁可关掉 Staggered HDR，切回 DCG 或普通模式。

2. 帧率下降：Staggered HDR 模式下，Sensor 的帧率会降到原来的 1/3（因为一帧时间要拍三帧）。如果 Sensor 的 VTS 是 3000 行，普通模式 30fps，Staggered 模式只能到 10fps。预览会卡顿。解决办法是：降低分辨率，或者只在高帧率场景（比如 60fps）下用 Short 帧做 HDR。

3. 读出带宽：三帧数据量是普通模式的三倍。如果 MIPI 通道数不够（比如只有 4 lane），带宽会爆。我遇到过 MIPI 时钟频率已经拉到 1.5Gbps，还是丢包。最后只能降低分辨率到 1080p。

四、QBC HDR：四合一像素，硬件级融合

原理一句话

QBC（Quad Bayer Coding）HDR 利用 Quad Bayer 排列的像素，将四个同色像素分成两组：一组用高增益（短曝光），一组用低增益（长曝光）。读出时，四个像素的数据合并成一个像素的 HDR 数据。本质上是“空间域”的 HDR，不牺牲帧率。

寄存器实现要点

QBC HDR 的配置通常和 Sensor 的 binning 模式绑定：

// 以 Sony IMX689 为例 // 先进入 QBC 模式：0x0100=0x00，然后写 0x0340 寄存器 write_sensor_reg(0x0100, 0x00); // 使能 QBC HDR：0x0340 bit[2]=1 // 别这样写：直接写 0x04，会清掉其他配置 uint8_t val = read_sensor_reg(0x0340); val |= 0x04; write_sensor_reg(0x0340, val); // 配置 QBC 分组：0x0341 寄存器控制哪两个像素用高增益 // bit[0]：0=左上+右下用高增益，1=右上+左下用高增益 // 踩坑：不同 Sensor 的分组方式不同，IMX689 和 IMX766 是反的 write_sensor_reg(0x0341, 0x00); // 默认分组 // 配置高增益和低增益的差值 // 0x0342：高增益相对于低增益的倍数，典型值 4x（即 2EV） write_sensor_reg(0x0342, 0x04); // 4x 增益差 // 配置读出模式：QBC HDR 通常需要 2x2 binning 输出 // 0x0343 bit[0]：0=正常输出，1=binning 输出 write_sensor_reg(0x0343, 0x01); // 使能 binning write_sensor_reg(0x0100, 0x01);

调试坑点

1. 分辨率损失：QBC HDR 输出的是 binning 后的数据，分辨率只有原始 Sensor 的 1/4。比如 50MP 的 Sensor，QBC HDR 输出只有 12.5MP。如果客户要求全分辨率 HDR，QBC 就不适用。

2. 色彩串扰：Quad Bayer 排列本身就有色彩串扰问题（同色像素之间），QBC HDR 把增益差异引入后，串扰会更严重。需要在 ISP 端做额外的 demosaic 和色彩校正。我调过一款 Sensor，QBC HDR 模式下红色通道的 SNR 比绿色低 6dB，最后靠改 ISP 的 Color Correction Matrix 才拉回来。

3. 动态范围上限：QBC HDR 的动态范围受限于增益差。如果增益差设为 4x（2EV），动态范围只能扩展 2EV。而 Staggered HDR 可以做到 6EV 以上。所以 QBC 适合中等动态范围场景（比如室内逆光），不适合大光比场景（比如日落）。

五、三种模式的选型建议（个人经验）

场景一：弱光 + 静态场景（室内、夜景）

推荐：DCG HDR
理由：DCG 不牺牲帧率，弱光下 HCG 能保证暗部信噪比。虽然动态范围不如 Staggered，但弱光场景本身光比不大，够用。
坑点：注意增益切换点的亮度跳变，可以在 ISP 端做帧间滤波。

场景二：大光比 + 运动场景（户外、运动）

推荐：Staggered HDR + 运动检测
理由：动态范围最大，能同时保留高光和暗部。但必须配合 ISP 的运动补偿，否则鬼影严重。
坑点：帧率下降，预览会卡。建议只在拍照模式用，视频模式慎用。

场景三：高分辨率 + 中等光比（人像、风景）

推荐：QBC HDR
理由：不牺牲帧率，分辨率虽然降到 1/4，但 12.5MP 对于手机屏幕够用。色彩串扰可以通过 ISP 校正。
坑点：动态范围有限，大光比场景会过曝或欠曝。

场景四：视频 HDR（4K 60fps）

推荐：DCG HDR 或 QBC HDR
理由：Staggered HDR 的帧率太低，无法满足 60fps。DCG 和 QBC 都能在单帧内完成 HDR，不丢帧。
坑点：DCG 的读出噪声在视频模式下会被放大（因为 ISP 的降噪强度有限），QBC 的分辨率损失在 4K 下不明显。

六、寄存器调试的通用原则

1. 先读后写：很多 Sensor 的寄存器是共享 bit 的，直接写会覆盖其他配置。养成先读、改 bit、再写的习惯。
2. 关流再改：大部分 HDR 模式切换需要先关流（0x0100=0x00），否则 Sensor 内部状态机乱掉，可能输出全黑或全白。
3. 等 2 帧：改完寄存器后，至少等 2 帧 VSYNC 再读数据。有些 Sensor 需要 1 帧来稳定内部 PLL。
4. 抓 raw 图验证：不要只看预览效果。抓 raw 图，用工具（比如 Imatest）分析动态范围和信噪比。我遇到过预览看起来很好，但 raw 图暗部全是噪声的情况。

七、最后说几句

HDR 模式选型没有银弹。DCG 简单可靠但动态范围有限，Staggered 动态范围最大但运动伪影和帧率是硬伤，QBC 平衡了分辨率和帧率但色彩和动态范围有妥协。我的建议是：在同一个项目中，根据场景动态切换 HDR 模式。比如室内用 DCG，户外用 Staggered，人像用 QBC。这需要 Sensor 驱动支持热切换（不关流直接改模式），虽然实现复杂，但效果最好。

另外，别迷信 Sensor 的 datasheet 上写的“最大动态范围 120dB”。那是实验室条件下测的，实际场景中，受限于读出噪声、运动伪影、ISP 处理能力，能到 80dB 就不错了。调试时，多抓 raw 图，多看信噪比曲线，比看参数表有用得多。

下次遇到 HDR 问题，先问自己三个问题：场景光比多大？有没有运动物体？帧率要求多少？答案出来了，选型自然就定了。