SDR 转 HDR 实测：只改标签、整体拉亮和静态曲线，同一帧差在哪

要点速览

SDR 转 HDR，是把按 100 尼特显示器制作的标准动态范围视频，变成按 ITU-R BT.2100 编码的 HDR 视频：传递函数换成 PQ 或 HLG，原色换成 BT.2020，位深至少 10 位，并且让高光真的亮过 HDR 参考白，而暗部和肤色基本不动。

本文用一帧开源电影画面，把三种能按公式算清的做法放在同一帧上实测，看清楚伪 HDR 伪在哪里，再讲 KwaFlux 的 AI 模型是怎样一步步算出 PQ 和 HLG 的，最后给出在 KwaFlux 里操作和自检的方法。PQ 和 HLG 怎么选，见下文。

• SDR 转 HDR 有两道关：信号要对（PQ 或 HLG、BT.2020、10 位、标签齐全），内容也要真的扩展（高光放开，暗部和肤色留在原处）。只过一道关的，都是伪 HDR。
• 我们拿同一帧 SDR，用三种做法转成 HDR，逐像素算出显示亮度。只改标签，天空被读成 6,207 尼特；整体线性拉亮，人脸到了 346 到 373 尼特，是 BT.2408 浅肤色参考范围（65 到 110 尼特）上限的 3 倍多。
• ITU 的 BT.2446 报告自己写明：线性拉亮不适合用来扩展亮度；报告里的三种方法都是静态的，跟画面内容无关。
• KwaFlux 的 SDR 转 HDR 是一个自研 AI 模型：线性化、扩到 BT.2020、PQ 或 HLG 编码都在模型里完成，亮度和色彩分两路处理，亮度强度是模型每一层都能看到的输入，内部 16 位，导出 10 位。
• 判断一段 HDR 做得对不对，不用靠眼睛猜：ffprobe 看标签，signalstats 量峰值和人脸亮度，本文给了命令和换算表。

怎样才算真的转成了 HDR？

真正的 SDR 转 HDR，既要信号合规，也要内容扩展。信号合规是格式层面的事：文件得是 PQ 或 HLG、BT.2020 原色、10 位或更高，标签和像素对得上。内容扩展是画面层面的事，ITU-R BT.2446 报告列了几条要求，大意如下：

• 暗部和中间调要尽量贴近原片，阴影里的细节不能被高光衬得看不见；
• 中间调不能抬得太高，否则画面平均亮度上去了，看久了不舒服；
• 高光要扩展到参考白以上，HDR 多出来的亮度主要花在这里；
• 亮度变了，颜色的观感要跟着调整，色相不能跑；
• 原片里的压缩瑕疵会被放大，压缩重的素材不该推得太亮。

只过信号这一关的文件，播放器会认成 HDR，画面却可能刺眼、发白或者跟原片没区别；只在画面上调得更亮更艳、不按 HDR 编码的，本质上还是一段 SDR。两种都是伪 HDR。

四种做法，先看一张表

①和②是最省事的两种。如果一个工具的 HDR 导出看起来只是整体变亮，用本文第 8 节的方法量一下，很容易看出是不是第②种。

同一帧实测：每个像素亮多少尼特

HDR 的效果在 SDR 网页上看不出来，截图再亮也只有 100 尼特左右。所以我们换一种看法：把每种做法输出的每个像素换算成显示亮度（尼特），再按亮度区间上色。蓝色和绿色是 SDR 屏能显示的范围，黄色是到 HDR 参考白 203 尼特为止，橙红是 203 到 1,000 尼特的高光，紫红和白色是 1,000 尼特以上。

怎么算的。 素材是 Blender 基金会的开源电影《Tears of Steel》（CC BY 3.0），1280 × 534 像素的 H.264 版本，按 BT.709 解码。原片亮度按 BT.1886（伽马 2.4，白场 100 尼特）计算。①把码值直接当 PQ 读，原色当 BT.2020 读；②先线性化，再乘 10，让白场落在 1,000 尼特；③按 BT.2446-1 报告第 4.2 节方法 A 的公式逐像素计算，目标峰值 1,000 尼特。所有亮度都按 BT.2020 的亮度系数算。图和下面的表只包含这三种做法。

框出来的区域取中位数，结果如下：

BT.2408 报告给 HDR 制作的参考：浅肤色 65 到 110 尼特，中等肤色 40 到 85 尼特，HDR 参考白 203 尼特。拿这把尺子量：

• 只改标签，天空被读成 6,207 尼特，远超大多数 HDR 电视能打出的亮度，人脸 513 到 636 尼特，是参考白（相当于一张白纸）的两三倍；黑色栏杆却几乎没变。暗的不动、亮的冲天，再加上 BT.709 的颜色被当成 BT.2020 读，整体又刺眼又艳。
• 线性拉亮，所有东西都乘了 10：人脸 346 到 373 尼特，是浅肤色参考上限的 3 倍多，黑栏杆从 2 尼特变成 20 尼特，暗部发灰。很多人说“开了 HDR 像蒙了一层白雾、脸像塑料”，原因就在这里。BT.2446 原文说得很直接：线性缩放会让平均亮度涨得太多，中间调亮到看着不舒服，不适合用来扩展亮度。
• BT.2446 方法 A 明显克制得多：人脸 163 到 180 尼特，天空 762 尼特，暗部只抬到 6 尼特。这部电影本身调得偏暗，原片人脸只有 35 尼特，所以人脸仍然高过参考范围，但比线性拉亮低了一半。

再看一帧大面积阴天：

只改标签时，50% 的像素超过 1,000 尼特，整帧平均 1,141 尼特，是原片的 29 倍；线性拉亮让整片阴天落在 400 到 1,000 尼特，像一堵发光的墙。BT.2446 也提醒过：大面积接近满白的画面，强扩展之后会亮得让人不舒服，所以它的方法 B 干脆把峰值压得更低。

补充： 这里的伪彩图只回答“每个像素被送到多少尼特”，不评价好不好看。HDR 好不好看，最后还要在 HDR 显示器上看。

把这几种做法画成曲线

把 SDR 信号从全黑一路推到满白，看每种做法输出多少尼特：

• 只改标签那条线，在信号 63% 左右就超过了线性拉亮，到满白冲到 10,000 尼特：PQ 的每个码值本来就对应一个固定的尼特数，SDR 的码值被它一读，意思全变了。
• 线性拉亮在对数坐标上是原片曲线整体平移：暗部也被抬了 10 倍，所以黑位发灰。
• BT.2446 方法 A 在暗部只比 BT.2408 的“不扩展”略高，越往高光走越陡。这是一条想得很周全的曲线，但它仍然只有一条：同一个亮度值，不管落在人脸、白墙还是云上，结果都一样。

BT.2446 报告在开头就承认了这一点：报告收录的三种方法都是静态的，处理方式跟内容和观看环境无关；自适应、动态、按区域变化的方法也存在，适合的动态方法可能在更多内容上表现更好。AI 反向色调映射就是往这个方向走的：映射不再是一条事先写好的曲线，而是模型从大量 SDR 与 HDR 的配对画面里学出来的。

KwaFlux 的 AI 模型怎样生成 HDR

KwaFlux 的 SDR 转 HDR 用的是自研模型。它不是“先用曲线猜一个 HDR，再让网络修一修”，而是把色彩科学直接做进模型的计算图里，模型最后一层交出来的就是可以直接编码的 HDR 信号。

色彩数学在模型里面。 进入网络的第一步，是按 SDR 的伽马把信号解码成线性光，这样后面每一次运算都对应真实的光量；然后从 BT.709 换进 BT.2020 的宽色域容器；最后在模型末端按 PQ 或 HLG 编码出去。中间没有外挂的 LUT，也没有导出时再拼上去的曲线，所以 BT.2020 的原色、PQ 的固定亮度、HLG 的相对亮度，在训练阶段就是模型必须满足的约束。

亮度和色彩分两路。 SDR 转 HDR 最常见的翻车，是整体抬亮之后人脸变成塑料、霓虹灯周围一圈发白。KwaFlux 把任务拆开：亮度分支专管光，让高光离开 SDR 那 100 尼特的天花板，同时把暗部和中间调留在原处；色彩分支负责在光变强的时候守住色相，天空还是那块蓝，口红还是那支红。上一节的实测说明了为什么要这样拆：只按亮度走的曲线，没法同时照顾人脸和云。

亮度强度是模型的输入，不是事后乘的系数。 不同片子要的 HDR 不一样：人像怕过亮，风光可以更开阔，夜景要让灯亮起来又不能把灯牌冲成一片白。KwaFlux 的亮度强度是 2.0 到 5.0 的连续值，模型每一层都能看到你选的是多少。拖动它时，光感和鲜艳度一起平滑变化，不像换了一张 LUT，也不会出现“只是整体乘了一个数”的效果。

同一套权重，PQ 和 HLG 都能出。 PQ 和 HLG 只是最后编码的传递函数不同，KwaFlux 用同一套模型权重交付两种格式，不需要为每种格式各训练一个模型，两种导出的画面也就一致。

内部 16 位，导出 10 位。 模型以 16 位精度、BT.2020 线性光计算，再按你选的色彩空间编码成 10 位的 H.265 或 AV1。高光被拉开之后，渐变需要更多色阶，中间结果不在 8 位上舍入，天空和墙面的过渡才不容易起色带。

轻量，所以能跑完一整条片子。 这个模型只做光和颜色：不做超分，不改构图，不往画面里加纹理。网络本身很小。显存紧张的机器会自动分块处理，画质目标不变，只是用更稳的方式跑完。

PQ 还是 HLG

两种格式怎么选，见上文「PQ 还是 HLG」。上传 YouTube 或交付 HDR10 时，导出选 PQ。

在 KwaFlux 里把 SDR 转成 HDR

第 1 步：打开 AI 调色，模式选 SDR 转 HDR。 在 AI 调色 里导入片段，模式选 SDR 转 HDR。它只处理视频；图片可以用智能调色或滤镜调色。

第 2 步：选场景。 场景 有 风光（默认）、夜景 和 自定义。风光和夜景用预设亮度（风光 3.8，夜景 3.5）；选自定义才会出现 亮度强度 滑块，范围 2.0 到 5.0。下面的起点是我们的建议，按你的片子再调：

第 3 步：先预览。 选 1、3 或 5 秒预览，挑画面里最亮和人脸最多的那一段。SDR 显示器上看到的是映射回 SDR 的版本，层次和肤色分离仍然看得出来；有 HDR 显示器的话，把系统 HDR 打开再看。

第 4 步：导出。 导出设置里，色彩空间 可选 HDR PQ (Rec.2020)（默认）、HDR HLG (Rec.2020) 和 SDR (BT.709)；编码可选 H.265（推荐）或 AV1，容器推荐 MKV。HDR 导出为 10 位，KwaFlux 会写入对应的传递函数、BT.2020 原色和矩阵，以及有限范围标签。

技巧： 素材本身糊、噪点多、压缩块明显时，先用画质修复清理，再做 SDR 转 HDR。HDR 会把原片的瑕疵一起放大，先修再扩，比扩完再修干净得多。

补充： SDR 转 HDR 目前不能叠加风格滤镜，叠加后导出会整体偏暗。已经调好的滤镜会保留，切回智能调色或滤镜调色即可使用。

不靠眼睛，也能检查 HDR 做得对不对

先看标签。 下面的命令列出色彩标签：

ffprobe -v error -select_streams v:0 -show_entries stream=pix_fmt,color_range,color_space,color_transfer,color_primaries -of default=nw=1 output.mkv

PQ 文件应该显示 smpte2084，HLG 是 arib-std-b67，原色和矩阵是 bt2020 与 bt2020nc，像素格式是 10 位（例如 yuv420p10le）。

再量峰值。 signalstats 能逐帧报出亮度分量的最大码值：

ffmpeg -i output.mkv -vf "signalstats,metadata=print:key=lavfi.signalstats.YMAX:file=ymax.txt" -f null -

对 10 位、有限范围的 PQ 文件，按下表把码值换回尼特（按 SMPTE ST 2084 公式计算）：

我们用一段 PQ 测试文件跑过这条命令，YMAX 报 715，对应约 920 尼特，和脚本逐像素算出的峰值 910 尼特一致。YMAX 是亮度分量（Y′），带颜色的高光会和真实亮度有些出入，用来判断数量级足够。如果大多数帧的 YMAX 都贴着 940，满白被读成了 10,000 尼特，多半只改了标签。

最后量一张脸。 判断是不是整体拉亮，看人脸比看峰值更准。挑一帧有正脸的画面，把脸框出来量平均码值（crop 的四个数是宽、高、左上角的横坐标和纵坐标，按你的画面改）：

ffmpeg -ss 10 -i output.mkv -frames:v 1 -vf "crop=30:40:712:100,signalstats,metadata=print:key=lavfi.signalstats.YAVG:file=-" -f null -

在本文那帧人像上，线性拉亮的版本量出 618 码值，约 330 尼特；BT.2446 方法 A 的版本是 549 码值，约 155 尼特。原片调得偏暗或偏亮，人脸的位置会跟着变，但人脸明显亮过参考白时，基本可以断定画面被整体抬亮了。

问题排查

AI 也做不到的事

• 找不回原片过曝溢出的细节。 SDR 里已经是一片 255 的天空或灯光，里面原来有什么，任何方法都只能推测，不能还原。
• 不会自动修好原片的压缩问题。 反向色调映射会放大原有的块效应和噪点，重压缩的素材要先修复。
• 不能替代 HDR 显示器。 在 100 尼特的屏幕上，HDR 只能映射回 SDR 来看；真正多出来的亮度，要在 HDR 屏上才看得到。
• 不会生成杜比视界的动态元数据。 KwaFlux 导出的是 PQ（HDR10 体系）或 HLG。

结语

伪 HDR 好做，改个标签或整体拉亮就能让播放器亮起 HDR 图标；真 HDR 要同时守住信号和内容两道关。下次看到一段“HDR”视频，可以用本文的两条命令量一量：峰值在哪里、平均亮度涨了多少，一测就清楚。

用你自己的真实素材实测效果

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

下载 KwaFlux · 查看方案