SDR 与 HDR 深度解析：PQ、HLG、色调映射与 HDR10 编码

要点速览

SDR 和 HDR 的根本区别，在于视频怎样把码值变成光。SDR 用的是围绕 100 尼特显示器设计的伽马曲线和 BT.709 色彩；HDR 用的是 ITU-R BT.2100 规定的 PQ 或 HLG 曲线、BT.2020 色彩、至少 10 位的位深，往往还带有元数据，告诉显示器母版有多亮。

• SDR 和 HDR 的差别分在四个层面：传递函数、色彩原色、位深和元数据。
• PQ 让每个码值对应一个固定的亮度，最高 10,000 尼特；HLG 的亮度相对于显示器峰值而定，所以不需要母版元数据。
• PQ 至少需要 10 位：按我们的计算，在 100 尼特附近，8 位 PQ 相邻码值之间的亮度跳变约 4.7%，10 位只有 1.1%。
• 色调映射把 HDR 的高光压进亮度更低的显示器：要么整部片子用一条静态曲线，要么靠动态元数据（HDR10+、杜比视界）逐场景调整。
• 标签只是给像素贴的说明。要改变像素的含义，必须做真正的转换；两者都可以用 ffprobe 检查。

什么样的视频才算 HDR？

HDR 视频的码值能描述比 SDR 宽得多的亮度范围，它用 ITU-R BT.2100 规定的 PQ 或 HLG 传递函数编码，以 BT.2020 原色、10 位或 12 位的位深承载。

这几个层面彼此独立：一个文件可以是 10 位的 SDR，也可以是不带元数据的 PQ。每个层面都有自己的标签，播放器读的是标签，不会根据像素去猜。

传递函数：BT.1886、PQ 与 HLG

传递函数决定信号值怎样映射成亮度。ITU-R BT.1886 把 SDR 的显示曲线定义为 2.4 次幂函数，参考白为 100 尼特；与之配套的 BT.709 摄像机曲线是 0.45 次幂，靠近黑位处有一小段线性部分。

PQ（SMPTE ST 2084） 以显示为参照：每个码值都对应一个确定的亮度，最高 10,000 尼特。BT.2100 说，PQ 用一条贴合人眼视觉的曲线，在给定位深下覆盖非常宽的亮度范围。按它的公式推算，100 尼特位于信号的 51%，203 尼特位于 58%，1,000 尼特位于 75%；信号范围的下半段只覆盖 0 到约 92 尼特。

HLG（ARIB STD-B67） 以场景为参照：信号描述的是相对的场景光，显示多亮由显示器决定。ITU-R BT.2390 报告介绍了它的形状：信号下半段是平方根曲线，与 SDR 接近；上半段改用对数曲线。BT.2100 规定，峰值 1,000 尼特的显示器系统伽马取 1.2，其他峰值按 γ = 1.2 + 0.42 log10(Lw / 1000) 调整，所以同一路 HLG 信号不靠元数据，也能适配 600 尼特的电视或 1,500 尼特的显示器。

补充： BT.2100 要求制作和显示统一使用其中一种体系，不要把 PQ 和 HLG 混在一起用。两者之间切换属于转换，不是改个标签。

色彩原色：BT.709 与 BT.2020

原色决定了信号能描述的最红的红、最绿的绿和最蓝的蓝。BT.709 的三原色在 CIE 1931 xy 色度图上位于 (0.640, 0.330)、(0.300, 0.600) 和 (0.150, 0.060)；BT.2100 采用 BT.2020 的原色，位于 (0.708, 0.292)、(0.170, 0.797) 和 (0.131, 0.046)。两者的白点都是 D65。按我们的计算，BT.2020 三角形的面积约为 BT.709 的 1.9 倍，但很少有母版能把它填满：调色监视器常见的是 P3-D65，x265 文档里给的母版显示器示例也是这一种。

同一种颜色在不同容器里的码值不一样：纯 BT.709 红换算到 BT.2020，线性 RGB 约为 (0.627, 0.069, 0.016)。不做转换就把 BT.709 的像素标成 BT.2020，所有颜色都会变艳；YouTube 也提醒过，用 P3 调色却标成 Rec. 2020 原色，画面会过饱和、色相偏移。

位深：PQ 为什么至少要 10 位

相邻码值之间的亮度跳变大到肉眼看得出来，就会出现色带；而 PQ 要把 0 到 10,000 尼特塞进 SDR 只用来表示 0 到 100 尼特的码值范围。我们根据 BT.2100 和 BT.1886 的公式，按窄范围码值算出了相邻码值之间的亮度变化：

在 100 尼特附近，10 位 PQ 的步长和 8 位 SDR 在白场处差不多细，同时还能覆盖到 10,000 尼特。BT.2390 把这些步长和基于 Barten 模型的可见阈值做了比较：12 位 PQ 从 10,000 尼特到 0.001 尼特以下都在阈值之下；10 位 PQ 略高于阈值，但报告指出，实际拍摄中的相机噪点会把它掩盖掉。

所以中间步骤至少保持 10 位，降到 8 位时要加抖动。我们测试时，zscale 的 d=error_diffusion 让色调映射后的暗部渐变保留了同样多的色阶，却把笔直的色带边缘打散成了细小的噪点。去色带的方法见8 位与 10 位视频。

HDR 元数据：静态与动态

HDR10 就是 10 位、BT.2020 原色的 PQ，再加上静态元数据：整部片子共用一份描述。

用静态元数据时，一部大多数场景偏暗、只有一场明亮爆炸的影片，整片只能用同一条曲线，而这条曲线得照顾那场爆炸。HDR10+ 说它的动态元数据能让显示器实时优化色调映射；杜比则说杜比视界能把每一帧画面映射到电视的能力范围内。HLG 不带母版元数据，靠显示器的系统伽马来适配。

技巧： 元数据要如实描述你的调色监视器和实测亮度。测不出 MaxCLL 时，x265 允许填 0，表示“未指明最大值”，这比随手估一个数靠谱。

色调映射：把 HDR 装进更暗的显示器

色调映射就是缩小画面的动态范围，让它适合显示器；ITU-R BT.2446 报告把反过来的过程称为反向色调映射。静态映射整部片子用一条曲线，通常根据母版峰值或 MaxCLL 来选；动态映射随时间变化，依据元数据或逐帧测量。BT.2390 提到，动态映射可以根据场景最大值这类统计量来调整。

EETF 先把 PQ 信号按母版范围归一化，在 KS = 1.5 × maxLum − 0.5 处开始拐点（maxLum 是目标峰值在这个归一化尺度上的位置），再把顶部压弯，让源的峰值正好落在显示器的峰值上。对 1,000 尼特的母版，显示器峰值为 100 尼特时拐点约在 28 尼特，300 尼特时约在 161 尼特。

FFmpeg 的 tonemap 滤镜实现了 clip、linear、gamma、Reinhard、Hable 和 Möbius 几种曲线。它的文档说，这些曲线只能处理浮点格式的线性光，所以滤镜链先用 zscale 转成线性光，做完色调映射再转回来：

ffmpeg -i hdr10.mp4 -vf "zscale=t=linear:npl=100,format=gbrpf32le,zscale=p=bt709,tonemap=tonemap=mobius:peak=10:desat=0,zscale=t=bt709:m=bt709:r=tv:d=error_diffusion,format=yuv420p" -c:v libx264 -crf 18 -color_primaries bt709 -color_trc bt709 -colorspace bt709 -color_range tv -c:a copy sdr.mp4

npl=100 表示线性值 1.0 对应 100 尼特，所以 peak=10 就是 1,000 尼特；设为 0 时，峰值从文件的元数据里读取。desat=0 关掉默认的高光去饱和，也就是不再把特别亮的像素往白色推。我们在一段 0 到 1,000 尼特的合成 PQ 渐变上测试，得到的 8 位输出码值如下（取平均值；有限范围，235 为白）：

clip 把 100 尼特以上的内容全变成同一种白；Hable 保留的高光层次最多，中间调也压得最暗；Möbius 在拐点以下原样保留。哪条曲线合适要看内容，请拿自己的素材比较。SDR 一侧的症状见视频导出后为什么发灰。

补充： tonemap 没有 BT.2390 模式；我们测试的 FFmpeg 8.1 版本里也没有 libplacebo、tonemap_opencl 和 tonemap_vaapi 滤镜，所以这几个没有测。

SDR 转 HDR：放进容器与扩展动态范围

放进 HDR 容器：保持画面原有的动态范围，只是重新编码成 PQ 或 HLG，让 SDR 素材能剪进 HDR 节目。BT.2446 指向 ITU-R BT.2408 报告介绍的做法，对齐的基准是 HDR 参考白，BT.2100 把它定为 203 尼特：

ffmpeg -i input_sdr.mp4 -vf "zscale=t=linear:npl=203,format=gbrpf32le,zscale=p=bt2020:t=smpte2084:m=bt2020nc:r=tv:npl=203,format=yuv420p10le" -c:v libx265 -preset slow -crf 18 -profile:v main10 -color_primaries bt2020 -color_trc smpte2084 -colorspace bt2020nc -color_range tv -tag:v hvc1 -c:a copy sdr_in_pq.mp4

我们测试时，SDR 的满白输出为 10 位码值 573，在 PQ 上就是 203 尼特；npl=100 时是 509（100 尼特），npl=1000 时是 723（1,000 尼特）。这样得到的是合规的 PQ 文件，但里面没有任何内容比参考白更亮。

扩展动态范围 就是反向色调映射：把高光抬到参考白以上，并扩大色彩范围。BT.2446 要求暗部和中间调尽量贴近原片，平均亮度也不能抬得太高、让人看着不舒服；它还提醒，扩展可能放大素材里原有的瑕疵。报告里的方法都是静态曲线，同时指出还有自适应、按区域变化的方法，基于 AI 的 SDR 转 HDR 就属于这一类。它和其他处理步骤怎样配合，见SDR 转 HDR 与补帧。

补充： 只改标签，这两件事都没做。10 位 SDR 的满白（码值 940）按 PQ 解读，会要求显示器打出 10,000 尼特。

用 x265 和 SVT-AV1 编码 HDR10

编码器需要写入 10 位档次、色彩描述和静态元数据。

x265 编码（HEVC Main 10）

ffmpeg -i master_pq.mov -c:v libx265 -preset slow -crf 18 -pix_fmt yuv420p10le -x265-params "profile=main10:colorprim=bt2020:transfer=smpte2084:colormatrix=bt2020nc:range=limited:hdr10=1:repeat-headers=1:master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,50):max-cll=1000,400" -tag:v hvc1 -c:a copy hdr10.mp4

-x265-params 里的每个键都对应一个 x265 命令行选项（--colorprim、--hdr10、--master-display 等）：

上面的原色取自 x265 文档里 P3-D65、1,000 尼特监视器的示例，请换成你自己监视器的参数。做 HLG 时，把传递函数设为 transfer=arib-std-b67，去掉母版参数，再加上 atc-sei=18，x265 文档说 HLG 信令需要它；完整命令见YouTube HDR 上传指南。hdr10-opt=1 会针对 10 位 4:2:0、BT.2020 PQ 输入打开 x265 的块级 QP 优化。

SVT-AV1（AV1，10 位）

ffmpeg -i master_pq.mov -c:v libsvtav1 -preset 6 -crf 30 -pix_fmt yuv420p10le -color_primaries bt2020 -color_trc smpte2084 -colorspace bt2020nc -color_range tv -svtav1-params "mastering-display=G(0.265,0.690)B(0.150,0.060)R(0.680,0.320)WP(0.3127,0.3290)L(1000,0.005):content-light=1000,400" -c:a copy hdr10_av1.mkv

SVT-AV1 的 CIE x、y 直接写小数，亮度直接写尼特；FFmpeg 会把 -color_* 参数传给编码器的色彩选项。在 FFmpeg 8.1 和 SVT-AV1 4.0.1 下，两条命令输出的都是 10 位文件，标签为 BT.2020、PQ 和 BT.2020 NCL，第一帧带有母版和亮度级元数据。

不重新编码也能补标签。 如果像素本来就是 PQ，hevc_metadata 比特流过滤器可以改写色彩描述，不动画面：

ffmpeg -i untagged.mp4 -c copy -bsf:v "hevc_metadata=colour_primaries=9:transfer_characteristics=16:matrix_coefficients=9" retagged.mp4

我们用一个 MP4 封装的 HEVC 测试文件试过，前后解码出的每一帧校验值都一致，标签从 unknown 变成了 BT.2020、PQ 和 BT.2020 NCL（代码分别是 9、16、9；HLG 是 18）。它不会补上 ST 2086 和 MaxCLL，这两项需要重新编码。

用 ffprobe 检查文件

ffprobe -v error -select_streams v:0 -show_entries stream=profile,pix_fmt,color_range,color_space,color_transfer,color_primaries:frame=side_data_list -read_intervals "%+#1" -show_frames -of json hdr10.mp4

一次调用就能拿到色彩标签和第一帧的附加数据。上面那个 x265 文件的输出如下：

这些数值按各编码自己的单位以分数显示：我们的 AV1 文件显示为 max_luminance=256000/256，同样是 1,000 尼特。HLG 文件显示 arib-std-b67，通常没有母版数据。按 HDR 调色的文件如果显示 bt709 或 unknown，播放时会被当成 SDR。

KwaFlux 怎样处理 HDR

• SDR 转 HDR 就是反向色调映射。 在 AI 调色 里，SDR 转 HDR 用 AI 模型把 SDR 片段向更宽的动态范围、更亮的高光和更清晰的暗部扩展。场景 决定效果：风光（默认）、夜景，或 自定义；选自定义时出现 亮度强度 滑块，范围 2.0 到 5.0（默认 3.8）。
• 导出选项。 色彩空间 可选 HDR PQ (Rec.2020)（默认）、HDR HLG (Rec.2020) 和 SDR (BT.709)，编码可选 H.265（推荐）或 AV1，容器推荐 MKV。HDR 导出为 10 位，SDR 为 8 位；导出设置会给每个选项配上对应的传递函数、BT.2020 原色和矩阵，以及有限范围标签。
• 交付前先检查。 对导出文件运行上面的 ffprobe 命令；如果平台要求 ST 2086 和 MaxCLL 而文件里没有，就用上面的 x265 参数重新编码。
• 在 SDR 屏幕上预览 HDR。 预览渲染器会解码 PQ 和 HLG，把 BT.2020 色彩转换到 BT.709，并用 Reinhard 类曲线压缩高光；它还有面向 HDR 输出的 HDR 直通模式。
• 修复与多步骤任务。 画质修复 的导出没有色彩空间选项，所以修复过的 HDR 文件要检查一下标签。多步骤任务的各步之间，KwaFlux 传递的是 10 位中间文件，8 位舍入误差不会累积成色带。

问题排查

这些方法做不到的事

• 色调映射没法在 100 尼特的屏幕上显示 1,000 尼特。 它只能取舍：保高光细节、保中间调对比度，还是保色彩。
• 反向色调映射找不回已经剪切掉的细节， 而且 BT.2446 提醒，扩展可能让压缩瑕疵显露出来。
• 元数据改不了调色。 它只描述母版，让显示器据此适配。
• 标签不会转换像素。 不做转换只改标签，画面就变了样。

结语

SDR 和 HDR 的区别不是一个决定，而是四个：曲线、原色、位深和元数据。每一项都要有意识地设置，再用 ffprobe 检查；画面需要在 SDR 和 HDR 之间转换时，就做真正的转换，而不是改个标签了事。

KwaFlux 在你自己的 GPU 上运行AI 调色，包括导出 PQ 或 HLG 的 SDR 转 HDR 视频。AI 处理在你自己的 GPU 上运行，媒体文件不会为了处理而上传。可在 Windows 10（64 位，1809 或更新版本）、Windows 11，以及搭载 Apple Silicon 的 macOS 12 或更新版本上运行。预览不需要账号：任意片段都能渲染 1、3 或 5 秒的预览。仅在导出、转换、文件修复和从链接下载文件时需要登录并购买付费方案。