📚 课程目录第1章 HDR技术概述

一、HDR技术概述：什么是HDR、HDR与SDR的对比、HDR的应用场景

1.1 什么是HDR？从一张照片说起

HDR，全称 High Dynamic Range，中文叫高动态范围。说白了，就是让画面「亮的地方更亮，暗的地方更暗，同时细节还不丢」。

我经常跟刚入行的同事打一个比方：你站在一个逆光的窗户前拍照，人脸是黑的，窗外是白的。普通相机只能二选一——要么人脸清楚，窗外过曝；要么窗外清楚，人脸死黑。HDR 呢？它把两样都给你保留下来。

从技术角度讲，HDR 的核心是扩展亮度范围和色彩深度。传统 SDR（标准动态范围）通常只能表示 0~100 nit 的亮度，而 HDR 可以覆盖 0.0005~10,000 nit 甚至更高。这中间的差距，不是「亮了一点点」，而是跨越了好几个数量级。

  关键指标对比：
  亮度范围：SDR 约 100:1 ~ 1000:1，HDR 可达 10,000:1 ~ 1,000,000:1
色深：SDR 通常 8-bit（256 级），HDR 要求 10-bit（1024 级）以上
色彩空间：SDR 用 BT.709，HDR 用 BT.2020（色域扩大约 70%）
传递函数：SDR 用 Gamma 曲线，HDR 用 PQ（Perceptual Quantizer）或 HLG

嗯，这里要注意：HDR 不是「把亮度调高」那么简单。它是一整套从采集、传输、处理到显示的链路升级。我在一个手机 ISP 项目中就踩过这个坑——软件端把图像亮度拉高就号称 HDR，结果噪点全出来了，暗部细节反而更差。后来老老实实做了多帧合成，才真正解决问题。

1.2 HDR vs SDR：不只是「更亮」

很多人以为 HDR 就是 SDR 的「增强版」，其实两者的底层逻辑完全不同。我整理了一张对比表，方便你快速理解：

对比维度	SDR（标准动态范围）	HDR（高动态范围）
亮度峰值	100 nit（典型）	1,000~10,000 nit
色深	8-bit（256 级/通道）	10-bit 或 12-bit（1024~4096 级/通道）
色彩空间	BT.709（约 35% CIE 1931）	BT.2020（约 75% CIE 1931）
传递函数	Gamma（幂律曲线）	PQ（ST.2084）或 HLG
数据量	较低（适合早期硬件）	2~4 倍于 SDR（需更高带宽）
典型应用	传统电视、旧手机、监控	旗舰手机、高端电视、专业安防

你想想看，8-bit 的 SDR 只有 256 个灰度级，而 10-bit HDR 有 1024 级。在暗部区域，SDR 可能只有 10~20 个可分辨的亮度台阶，HDR 却有 100 级以上。这就是为什么 HDR 画面看起来「有层次感」——不是玄学，是数学。

我的经验：在做 HDR 硬件架构时，千万别把 SDR 的 Gamma 曲线直接套用到 HDR 上。PQ 曲线是感知均匀的，Gamma 曲线不是。我曾经见过一个团队用 Gamma 做 HDR 色调映射，结果画面整体偏灰，暗部细节全被压缩了。后来换成 PQ 曲线，效果立竿见影。

1.3 HDR 的应用场景：手机、电视、安防

HDR 不是实验室里的概念，它已经大规模落地了。我挑三个最典型的场景来讲：

1.3.1 手机端：多帧合成与实时预览

手机是 HDR 最普及的战场。你随手拍一张逆光照片，背后就是一套完整的 HDR 流水线：

多帧采集：连拍 3~5 帧，分别对应短曝光、中曝光、长曝光
对齐与去鬼影：运动物体在不同帧之间会位移，需要做运动估计和补偿
权重融合：每帧取信噪比最高的区域，合成一张宽动态图
色调映射：把 10-bit 或 12-bit 的 HDR 数据压缩到 8-bit 显示

我在做手机 ISP 的 HDR 模块时，最头疼的是「去鬼影」。你想想看，拍合影时有人眨眼了，或者风吹动了头发，多帧合成就会出现重影。后来我们用了基于光流的运动补偿，才把鬼影率从 15% 降到 1% 以下。

1.3.2 电视端：高亮度面板与 PQ 曲线

电视端的 HDR 更强调「显示能力」。一台合格的 HDR 电视需要：

峰值亮度 ≥ 1,000 nit（OLED 通常 600~800 nit，Mini-LED 可达 2,000 nit）
10-bit 面板（8-bit + FRC 是伪 HDR，我不推荐）
支持 PQ 或 HLG（HLG 兼容性好，PQ 画质上限更高）

电视端的 HDR 标准主要有两个：Dolby Vision（12-bit，动态元数据）和 HDR10（10-bit，静态元数据）。我个人更看好 Dolby Vision，因为它的逐帧动态元数据能更精细地控制亮度映射。但 HDR10 胜在免费且普及率高。

避坑指南：我曾经测试过一款号称「HDR 电视」的产品，面板峰值亮度只有 400 nit，色深是 8-bit + FRC。播放 HDR 内容时，暗部全是色带，亮部细节全无。这不是 HDR，这是「HDR 模式」——一种软件模拟的噱头。真正的 HDR 必须硬件达标。

1.3.3 安防监控：宽动态（WDR）与 HDR 的融合

安防场景对 HDR 的需求其实比消费电子更迫切。你想想看，一个监控摄像头装在门口，白天阳光直射，晚上只有微弱路灯。传统 SDR 摄像头要么白天过曝，要么晚上全黑。

安防领域的 HDR 通常叫 WDR（宽动态），但本质是一回事。区别在于：

帧率要求高：安防需要 25~30fps 实时处理，不能像手机那样拍完再算
低光性能优先：安防更看重暗部细节，亮部可以适当牺牲
硬件成本敏感：不能上太贵的传感器和 ISP

我在一个安防项目中做过「双帧 HDR」方案：一帧短曝光（1/1000s）保留亮部，一帧长曝光（1/30s）保留暗部，两帧在 ISP 内实时融合。延迟控制在 1 帧以内，效果比单帧 WDR 好很多。

1.4 HDR 合成硬件架构概览

讲完了概念和应用，我们来看一下 HDR 合成的核心硬件架构。下面这张图是我在多个项目中总结出来的通用流水线：

这张图是 HDR 合成硬件架构的「骨架」。后面的章节，我会逐一拆解每个模块的 RTL 实现细节——从运动估计的流水线设计，到权重融合的乘法器优化，再到色调映射的查找表实现。

一个小建议：如果你刚开始接触 HDR 硬件设计，建议先从「权重融合」模块入手。它逻辑相对简单，但涉及大量的并行乘加运算，是理解 HDR 硬件并行性的好起点。我在带新人时，通常让他们先写一个 3 帧融合的 Verilog 模块，跑通仿真后再加运动估计。

1.5 本章小结

这一章我们聊了 HDR 的本质——不是简单的「拉亮」，而是亮度范围、色深、色彩空间和传递函数的全面升级。SDR 和 HDR 的差距，就像黑白电视和彩色电视的差距一样，是代际性的。

三个应用场景各有侧重：手机拼算法（多帧合成+去鬼影），电视拼面板（亮度+色深），安防拼实时性（低延迟+低光性能）。但无论哪个场景，底层的硬件架构都离不开「多帧输入 → 对齐融合 → 色调映射」这条主线。