HDR发灰不是调亮度：SDR/HDR编码与色调映射排查指南

一条HDR母版送到对方手上，反馈回来的第一句话往往是“怎么看着灰蒙蒙的”。这时候最没用的回应就是“你把亮度调高一点”——因为问题八成不在亮度旋钮上。我在几个交付项目里反复遇到过同类现象：有人拿SDR的观看习惯去判断HDR素材，有人把PQ编码的码值当普通伽马去解，还有人用截图工具截了一张HDR画面发到群里说“颜色不对”。这些场景背后指向同一件事：SDR与HDR是两套不同的信号编码体系，不是同一套体系里亮度高低的两档。把这句话嚼透，很多看似玄学的问题会立刻变得可解释。这篇内容面向刚接触HDR调色、转码、播放链路排查的从业者，也面向想搞清楚“我买的屏幕到底支不支持”的普通用户，从最基础的动态范围讲起，一路讲到元数据、色调映射和实际排查手法，中间该算的账我们算清楚，该踩的坑我按自己踩过的顺序摆出来。

1. 从“发灰”这个现象倒推：SDR与HDR改的是整条链路

先把最常见的误解放这儿：很多人以为HDR就是“亮的更亮、暗的更暗”，等价于给SDR画面拉一条S曲线。按这个理解去操作，得到的是一条对比度爆炸、高光糊成一片的废片。真实情况是，HDR从拍摄端的传感器、到信号编码、到传输容器、到显示端的驱动，每一环都换了一套参数约定，任何一环没对上，最终观感就会跑偏。

1.1 动态范围的三个层次：场景、信号、显示

“动态范围”这个词在不同的语境里指的不是同一个东西，混用是理解混乱的源头。我在带新人的时候通常要求先把这三层分清：

人眼的瞬时动态范围大约在 10^4 量级，靠瞳孔和适应机制还能再扩展。SDR 体系把信号的有效区间压在参考白 100 尼特附近，等于主动放弃了场景里绝大部分高光信息；HDR 体系把这个天花板抬到 1000 尼特甚至更高，同时把暗部编码精度也提上去，才有了“两头都打开”的效果。

理解这一层很关键：HDR 不是让画面整体变亮，而是让“亮部还有细节”这件事成为可能。一片雪地在SDR里只能是一块接近纯白的平面，在HDR里才能看出雪粒的层次和阴影，因为它有足够的亮度余量去承载这些差异。

1.2 100尼特这条参考白，为什么是整件事的锚点

SDR 的整个体系是围绕“参考白 100 尼特”建立的。你在标准亮度的监视器上调色，画面里一张白纸的亮度就应该是 100 尼特左右，观众家里的电视不管实际亮度多少，理想情况下也应该把这一级还原成接近参考白的感觉——所以SDR本质上是相对亮度体系，它描述的是“这一级比那一级亮多少”，而不是“这一级绝对是多少尼特”。

HDR 打破了这个约定。在 PQ 体系里，每一个码值都对应一个绝对亮度，码值 0.5 就是 92 尼特上下，不管你在什么设备上看，这个映射关系是固定的。好处是内容创作者的意图可以被精确保留，坏处是——当显示设备的峰值亮度达不到内容要求的亮度时，必须有一套机制去“压缩”，这就是后面要讲的色调映射。

搞清这一点，就能解释一个非常常见的困惑：为什么同一部HDR片子，在高端电视上看着通透锐利，在普通显示器上却灰扑扑的。前者有余量去还原高光，后者只能压缩，压缩策略不好就变灰。

2. 伽马、PQ、HLG：同一个码值究竟代表多少光

传递函数是HDR里最不直观、也最容易出错的一环。它做的事情其实很朴素：把物理亮度转换成 0 到 1 之间的码值，方便存储和传输。人眼对暗部的变化远比亮部敏感，所以这个转换必须是非线性的，把更多码值分配给暗部。SDR、PQ、HLG 三者的区别，就在于这条非线性曲线长什么样。

2.1 SDR的伽马曲线与BT.1886

早期显示器是阴极射线管，它的亮度响应天然接近幂函数，指数大约在 2.2 到 2.4 之间。后来这套特性被写进了标准，形成了显示端伽马 2.4 的约定，配合内容端的反向编码，最终端到端还原出线性光。BT.1886 就是把这个约定规范化的文件，它规定了在纯黑为 0 的理想显示器上，输入信号与输出亮度的对应关系。

实际计算很简单：码值记作 V，显示亮度约等于 100 × V^2.4 尼特。码值 0.5 对应大约 18.9 尼特，码值 0.8 对应大约 58.6 尼特，码值 1.0 对应 100 尼特。这条曲线在暗部爬得很慢，这正是我们需要的——暗部细节的码值被拉得很开。

问题在于这条曲线的顶端被钉死在 100 尼特。假如你想表达一个 1000 尼特的太阳，在SDR里没有任何码值能表示它，只能让它和 100 尼特的白纸一样白。这就是SDR的物理上限，不是调色能解决的。

2.2 PQ把“绝对亮度”写进了码值

PQ（Perceptual Quantizer，感知量化）曲线的设计目标是：在 0 到 10000 尼特这个巨大范围内，让每一个码值之间的亮度差异都刚好落在人眼能分辨的临界点上，不多不少。它是在人眼视觉模型基础上反推出来的，标准文件里对应 ST 2084。

我实测算过几个关键点位，对建立直觉很有帮助：在 10bit 编码下，码值 512（归一化后约 0.5）对应约 92 尼特，码值 800 上下对应约 1500 尼特，码值接近满量程才触及 10000 尼特。也就是说，PQ 把绝大部分码值资源投入到了 0 到 100 尼特这个区间，因为这个区间才是人眼日常观看的主体，高亮度段的码值反而稀疏。

这个特性和直觉相反，但极其重要：HDR 视频的“信息量”主要堆在暗部和中间调，而不是高光。很多人以为HDR的关键是高光有多亮，其实关键是暗部有多干净、中间调有多细腻。判断一条HDR素材质量高低，我更愿意看它在 5 到 50 尼特区间的层次，而不是峰值能冲到多少。

PQ 是绝对亮度编码，这意味着它和显示设备的峰值亮度是解耦的。内容写的是 1000 尼特，显示器只有 400 尼特，中间必须有个转换环节，这个环节做得好不好，直接决定了观感。这也是为什么“支持HDR”这四个字信息量极低——支持到什么程度、怎么处理超出能力的部分，才是关键。

2.3 HLG为向下兼容留的那条后路

HLG（Hybrid Log-Gamma，混合对数伽马）是另一套思路。它的曲线在低段沿用伽马特性，高段切换成对数特性，整体设计成相对亮度体系，并且刻意做到了“不认HDR的设备也能看个大概”。

这个设计初衷非常务实：广播电视系统里存在海量不支持HDR的终端，如果一套信号只能在HDR设备上正常显示，那播出方就得同时传两路流，成本翻倍。HLG 让同一路信号在SDR终端上显示时对比度略平但可接受，在HDR终端上则能还原出扩展的高光。

代价是 HLG 不像 PQ 那样能精确定位绝对亮度，它更接近“场景参考”，具体亮度取决于显示设备的系统伽马设置。所以在需要精确控制观感的影视交付场景里，PQ 用得更多；在直播、广播这类要求兼容性的场景里，HLG 更常见。

注意：PQ 和 HLG 是两套不兼容的编码方式，混用会导致严重的亮度错位。一条标注为 HLG 的素材被当作 PQ 解码，画面会明显发闷发暗；反过来则会过曝。转码时务必确认传递函数标记有没有跟着一起转。

3. 色域与色深：被亮度话题盖住的另一半

聊HDR的时候，十个人里有九个只谈亮度，剩下一个谈色域。实际上色域和色深的改动幅度一点不比亮度小，而且在很多“看着不对劲”的案例里，问题恰恰出在这一半。

3.1 BT.709到BT.2020：容器大了一圈，内容不一定跟着变

SDR 时代的色域标准是 BT.709，它的三个基色坐标定义了一个不算大的三角形，覆盖可见光谱色度图大约三分之一出头的面积，基本上等同于常见的 sRGB。HDR 配套的容器是 BT.2020，基色坐标大幅外推，覆盖面积接近色度图的四分之三。

但这里有个关键区别：BT.2020 是容器，不是内容。绝大多数HDR内容的实际色域远没有填满 BT.2020，尤其是实拍素材，很多只比 BT.709 略宽一点。真正吃到宽色域红利的主要是高饱和的人造色，比如霓虹灯、荧光涂料、LED 屏幕这类。

这个区别带来的实操影响是：转码时如果把 BT.2020 标记写成 BT.709，或者干脆不写，播放端按 BT.709 去解释 BT.2020 的色度坐标，颜色会明显走样，常见的是红色和绿色偏得厉害，整体偏色发闷。这类问题在元数据缺失的文件里特别常见，尤其是经过几道转手、被某些工具“顺手”改过标记的素材。

我一般的做法是：拿到任何一条HDR素材，先用工具把色彩原色、传递特性、矩阵系数三个标记读出来，确认是 BT.2020 / PQ 的组合，还是 BT.2020 / HLG，或者是标错的 BT.709。这一步花不了两分钟，能省掉后面几个小时的无头苍蝇式排查。

3.2 10bit不是“更细腻”这么简单，算一笔梯度账

HDR 起步就是 10bit，这是硬性要求，不是可选升级。原因藏在 PQ 曲线的形状里。

前面算过，10bit 下码值 512 对应约 92 尼特。那么相邻两个码值之间的亮度差是多少？在 92 尼特附近做微分估算，大约每格 1 尼特左右。也就是说，10bit 在中间调区域的亮度分辨率约为 1%。

同样是这个亮度位置，8bit 编码只有 256 级，一格对应归一化步长约 1/255，折算到亮度上大约是 3.7 尼特，相对误差接近 4%。人眼在均匀背景下的亮度辨别阈值大约在 1% 到 2%，4% 的步长已经超出阈值，表现出来就是渐变区域出现明显的台阶——天空渐变会出现一圈圈的色带，暗部会断层，肤色过渡会发脏。

进一步说，8bit 最致命的问题在暗部。PQ 把大量码值分配给了低亮度，8bit 的最暗几级之间跨度极大，暗部几乎是一格一跳，压缩噪点和暗部细节全部丢失。这也是为什么很多“伪HDR”内容一看暗部就露馅：用的是 8bit 源，撑不起 PQ 的精度要求。

顺带说一句色度采样。4:2:0 在 HDR 里依然是主流，因为人眼对色度分辨率的敏感度低于亮度。但HDR的高饱和度色块更多，4:2:0 在饱和度突变的边缘更容易出问题，比如红色霓虹灯的边缘会出现色度溢出。这不是说要用 4:4:4 交付，而是调色和质检时要特意看一眼这类区域。

4. 元数据：设备之间怎么“打招呼”

元数据是HDR里最抽象的部分，但它决定了整条链路能不能对上号。用个类比：元数据相当于随货物附的一张说明卡，告诉接收方“这件货最亮的地方是多少尼特、平均多亮、是在什么显示器上调的”。没有这张卡，接收方只能靠猜。

4.1 静态元数据的三个关键字段

最常见的静态元数据方案（业内常说的 HDR10 一档）携带三个核心字段：

• 母版显示信息：记录调色时用的监视器参数，包括最大亮度、最小亮度、基色坐标。它描述的是“创作环境”，用于让接收端理解创作意图。
• 最大内容亮度：整条片子中出现的最高像素亮度，单位尼特。播放器据此判断是否需要压缩。
• 最大帧平均亮度：所有帧的平均亮度里的最大值。这个字段对局部调光设备特别重要，因为它决定了背光能开多亮。

这三个字段的价值在于给播放端提供决策依据。举个例子：一条片子的最大内容亮度是 1000 尼特，播放端屏幕峰值只有 600 尼特，那它就知道需要做一次 1000 到 600 的压缩；如果这条片子的最大内容亮度只有 400 尼特，那 600 尼特的屏幕可以原样直通，一个像素都不用改，画质损失为零。

问题在于静态元数据是整条片子一个值。一部电影里有夜戏也有白天外景，夜戏可能最亮只有 200 尼特，白天外景冲到 1000 尼特，静态元数据只能取那个 1000 尼特。结果就是夜戏也被按 1000 尼特去处理，在能力不足的屏幕上被过度压缩，白白损失了对比度。

4.2 动态元数据解决了静态元数据解决不了的问题

动态元数据的思路是逐场景、甚至逐帧下发亮度信息。夜戏报 200 尼特，播放端就不用压缩；切到白天外景报 1000 尼特，再启用压缩策略。理论上画质最优。

代价是整条链路都得支持：编码器要能写入，封装格式要能承载，播放设备要能解析，任何一环掉链子就退化成静态元数据甚至完全失效。实际项目里我遇到过封装环节把动态元数据丢了的情况，输出文件在支持的设备上和不支持的设备上观感差异很大，排查了半天才发现是中间某个工具不认这个字段。

选型上的经验是：如果交付目标平台明确支持某种动态元数据方案，并且你的工具链从头到尾都验证过，那就用；如果中间有任何不确定，老老实实用静态元数据，把最大内容亮度填准确，比塞一堆解析不了的数据靠谱得多。填错的最大内容亮度比不填更糟糕——填 1000 实际只有 300，播放端会做多余的压缩，画面直接被压平。

5. 一条HDR片子从母版到屏幕要过的几道关

理解了原理，再来看流程。一条HDR内容从制作到最终被看到，中间要经过母版、编码、封装、传输、解码、渲染六个环节，每个环节都可能成为画质损失的来源。

5.1 调色与母版：亮度定在哪，决定了后面所有事

母版亮度是第一个决策点，也是影响最大的一个。常见的目标有 1000 尼特和 4000 尼特两档，前者更贴近消费级显示设备的实际能力，后者留的余量更大但对播放端要求更高。

这个决策不能拍脑袋。我参与的項目里，如果内容主要面向普通家庭观看，母版峰值定在 1000 尼特是比较务实的选择，因为市面上大部分设备的实际峰值就在这个量级附近，压缩幅度小，观感稳定。如果内容面向影院或高端演示场景，才考虑更高的母版亮度。

调色环节还有一个容易被忽略的点：监看环境。HDR 调色对暗室环境的要求比SDR严格得多，因为暗部细节在环境光干扰下根本判断不准。我见过在黑窗帘都没拉严的房间里调HDR的项目，成片在标准环境下一看，暗部全糊在一起。这不是技术问题，是环境问题，但结果一样严重。

另一个实操细节：调色时要有意识地在 100 尼特附近建立“舒适区”。观众的观看环境千差万别，中间调才是绝大多数画面的主体，把中间调处理好，比把峰值亮度冲到多高重要得多。我个人的习惯是每隔一段时间把画面切到模拟SDR的预览上看一眼，确认降级之后主体信息没有丢失。

5.2 编码、码率与传输：HDR的带宽账

HDR 内容对编码的要求比SDR高，原因不在分辨率，而在精度。10bit 相比 8bit 直接让原始数据量增加 25%，而 PQ 曲线带来的暗部精细梯度对编码器的量化策略也更敏感——量化粗糙一点，暗部就出块。

主流做法是用支持 10bit 的编码配置，码率相比同分辨率SDR上浮三到五成。这个上浮不是拍脑袋定的，来源是两部分：位深增加带来的固定开销，以及为保住暗部梯度需要降低量化强度带来的额外开销。

码率给不够的典型症状是暗部出现色块和蠕动噪点，尤其是在大面积的暗场加微弱光源的画面里。这类问题在监视器上可能不明显，投到大屏上就非常刺眼。质检的时候我通常会专门找一段暗场戏，暂停在画面上放大看暗部，这比看高光更能发现问题。

传输环节还有个坑：某些分发链路会对视频做二次转码，转码时如果没保留色彩标记，元数据就丢了。这类丢失是静默的，文件能播，就是颜色不对。所以交付前必须对最终分发出去的成品做一次完整回读，而不是只检查本地母版。

5.3 播放端的能力协商与回退

播放端做的事情比想象中复杂。它需要读取内容的元数据，读取自身屏幕的能力参数，然后决定是直通、压缩还是降级到SDR输出。这个决策链里任何一步判断错误，观感就崩。

常见的错误判断有三类。一类是屏幕实际峰值远低于厂商标称值，标称 1000 尼特实际全屏亮度只有 400 尼特，按 1000 去协商就会导致高光被硬削。第二类是播放器根本不读元数据，一律按固定曲线处理。第三类是系统层面的色彩管理没开，播放器输出的是正确的信号，但合成环节又给转了一道。

这三类问题在排查时的表现很像，都是“颜色不对、亮度不对”，但解决路径完全不同。所以我的排查顺序永远是：先确认内容本身标记正确，再确认播放器有没有正确解析，最后确认系统合成环节有没有二次处理。这个顺序是从内到外，能避免在错误的方向上浪费时间。

6. 色调映射：同一部片子在两块屏上长得不一样

色调映射是HDR落地环节里技术含量最高、也最没有统一答案的部分。它的任务是把超出显示能力范围的亮度压回可用区间，同时尽量保持观感。

6.1 峰值亮度不够时的三种压缩思路

面对一条峰值 1000 尼特的内容和一块峰值 400 尼特的屏幕，至少有三种处理方式：

第三种是现在的主流方向，但各家的实现差异极大，这也是为什么同一部片子在两块不同品牌的屏幕上观感能差出一截。作为内容方，能做的是把母版做好、元数据填准，剩下的交给设备；作为观看方，能做的是理解这种差异是正常的，不必因为“在我这看着不如演示片”就怀疑片源。

有个反直觉的结论值得记住：在能力不足的屏幕上，一条母版亮度适中的片子，观感往往好过一条母版亮度拉到极限的片子。因为前者需要的压缩量小，损失少；后者需要大刀阔斧地压，中间调必然受牵连。

6.2 局部调光与ABL对画面的实际影响

分区背光设备还有个特殊现象：光晕。暗场里有一个小面积高光，比如夜空中的月亮，高光所在分区的背光要开亮，物理上会照亮周围区域，形成一圈雾状光晕。分区数越少、分区面积越大，光晕越明显。

这是硬件物理限制，不是缺陷。但它会影响内容制作：如果画面里经常出现小面积极高亮度的元素配大面积暗背景，在分区背光设备上的观感会明显劣化。调色时如果能预判到主要观看设备类型，适当控制这类画面的亮度峰值，观感会更稳。

另一个机制是平均亮度限制。屏幕为了保护背光和散热，会在画面整体很亮时主动降低输出。这意味着一条全屏雪景的镜头，实际亮度可能被压到远低于峰值。这个机制在播放端不可控，内容方只能通过控制整体亮度水平来减少触发频率——这也是为什么很多HDR规范会给出一个“建议的平均亮度上限”。

7. 我踩过的几个坑和对应的排查链路

原理讲完了，下面是真正花时间的部分。这些问题我在不同项目里都遇到过，排查过程记录下来，希望能帮人少走点弯路。

7.1 素材发灰：从容器、元数据到渲染链逐层定位

现象：一条HDR母版在某台机器上播放，整体发灰、暗部抬亮、颜色寡淡，看起来像加了一层雾。

我的排查顺序是这样的：

第一步，读容器信息。用工具把文件的编码格式、位深、色彩原色、传递特性、矩阵系数全部打出来。这一步要确认三件事：位深是不是 10bit 以上，传递特性是不是 PQ 或 HLG，色彩原色是不是 BT.2020。任何一个不对，问题就定位在文件本身。

第二步，看元数据字段。最大内容亮度、最大帧平均亮度、母版显示信息是否存在，数值是否合理。如果最大内容亮度填的是 0 或者明显异常，播放端就会走默认处理逻辑，很容易出问题。

第三步，换播放器验证。同一个文件在两个不同播放器上播放，如果表现一致，说明问题在文件或系统层；如果不一致，说明是播放器解析能力差异。

第四步，检查系统色彩管理。这一步最容易被跳过。某些系统会把播放器输出的HDR信号再做一次转换，转换策略不对就会发灰。验证方法是把播放器设置成窗口模式，和桌面上的SDR内容对比，如果整个桌面都发灰，那问题在系统层。

按这个顺序走，绝大多数发灰问题能在十分钟内定位到具体环节。最忌讳的做法是一上来就怀疑片源，然后重新导一遍，导了三次发现还是灰的，最后才发现是系统设置。

7.2 截图偏色与“伪HDR”的快速识别

截图是另一个高频问题。用普通截图工具截一张HDR画面，得到的图往往发灰、过曝或者偏色。原因很简单：截图工具通常不做色调映射，直接把 PQ 码值当普通图像数据保存，等于把绝对亮度编码当成了相对亮度数据。

正确做法是用支持HDR截图的工具，或者在播放器里切换到SDR输出模式再截。用截图来判断HDR画面的颜色是不靠谱的，我见过太多在群里发截图说“你们这个颜色不对”的沟通，最后发现是截图工具的问题。

至于“伪HDR”的识别，几个快速判断点：

• 位深只有 8bit 的，基本可以判定撑不起真正的HDR精度。
• 用亮度分析工具看波形图，如果高光部分是一条平线，说明是从SDR拉曲线硬转的，高光信息是编出来的。
• 最大内容亮度标称 1000 尼特，但实际画面最高亮度只有两百多尼特，说明是虚标。
• 暗部细节一片死黑或者噪点被强行拉亮，也是转制的典型特征。

这些判断不需要专业设备，普通工具就能做，对于需要验收素材的场景很有用。

7.3 SDR兼容版本不是简单压暗

绝大多数HDR项目还要交付一个SDR版本，因为观看端不可能全是HDR设备。这一步的常见错误是把HDR画面整体压暗了事，结果SDR版本暗部全黑、高光全灰。

正确的做法是做一次独立的色调映射，把 HDR 的亮度范围压缩到SDR的 100 尼特参考白体系里，同时要保持中间调的相对关系。这里有个关键点：不能简单按比例缩放。PQ 曲线和伽马曲线的形状完全不同，直接按比例缩放会导致中间调偏离正确位置，观感上就是“灰”或者“闷”。

实践中常见的做法是使用专门的色调映射算法，或者由调色师在HDR母版基础上再做一版SDR调色。后者成本高但效果最可控，前者效率高但需要针对内容类型调参。我的经验是：内容里高光和暗部跨度大的，值得单独调一版；内容本身比较平缓的，算法映射就够用。

还有一点提醒：SDR版本也要保留正确的色彩标记，否则播放端会按错误的色域解释，颜色同样会偏。这一点在交付检查清单里必须单列一条。

8. 一份可以直接照着核对的检查清单

把上面这些内容压缩成一张表，交付前过一遍，能挡掉大部分低级错误。

最后分享一个小习惯：我每次交付前都会把成片在三种环境下各看一遍——HDR显示器、普通SDR显示器、以及手机。手机这一遍最容易发现问题，因为移动端的播放链路和色彩管理跟桌面完全不同，很多在专业监视器上看不出来的问题，在手机上会放大。有一次就是在手机上发现字幕的白色亮度远超画面主体，在HDR下刺眼得厉害，回头把字幕亮度单独限了一下才解决。这类细节不会写在任何规范里，只能靠多看多试积累。