上周帮一个朋友看他剪的片子，他把一段 HDR 素材拖进时间线，改了两刀就直接导出，结果画面灰蒙蒙一片，天空没了层次，人脸像蒙了一层塑料膜。他第一反应是"软件坏了"，第二反应是"是不是我显示器不行"。我看了下他导出的文件，色彩标记写着 BT.2020、传输函数写着 PQ，但画面里完全是按 SDR 的逻辑在处理。这就是最典型的一类问题：HDR视频与SDR视频不是"亮一点暗一点"的区别，而是两套从采集、编码、传输到显示完全不同的信号定义体系，任何一环对不上，画面就会塌。
这篇东西我想把 HDR 和 SDR 这套概念从头到尾捋一遍。不是念标准文档，而是按我自己做片子、转码、排错的顺序来讲：动态范围到底指什么、色域和传递函数为什么是绑在一起的三根柱子、市面上几种 HDR 格式各自在解决什么问题、真到动手把 HDR 母版转成 SDR 交付时参数该怎么算、以及那些文档里不会写但一定会踩的坑。适合刚开始接触 HDR 调色或者转码的朋友，也适合已经做过几个项目但一直靠"试出来"的人——把这套底层逻辑补上，后面很多现象你一眼就能判断出问题出在哪一层。
1. 先把底层概念掰开：动态范围到底在说什么
1.1 从感光宽容度到显示亮度：动态范围的两层含义
"动态范围"这个词在三个地方被反复使用，但含义完全不同，混着用是很多误判的源头。第一层是场景动态范围，也就是真实世界里一个画面最亮和最暗部分的比值。晴天正午的云层边缘反射亮度能到几万尼特，而同一画面里背光处的深色衣物可能只有个位数尼特，两者比值轻松超过一万比一。第二层是相机感光宽容度，传感器能同时记录下来的亮度区间，全画幅机器在原生 ISO 下大概能覆盖十几个档，换算成亮度比值大约是几千到一万多。第三层才是我们做后期最关心的显示动态范围，也就是一块屏幕能同时呈现的最亮与最暗的比值。
这三层不是一回事。场景里有十万比一的亮度落差，相机只记下来一万比一，显示器只能放出几千比一，每一层都在做压缩和取舍。SDR 显示器的对比度典型值在一千比一到四千比一之间（液晶靠背光调制，OLED 的黑色更干净），而 HDR 显示设备的目标是把同时可呈现的亮度区间推到十万比一这个量级。注意"同时"两个字很关键——不是把整块屏幕调亮，而是在同一帧画面里，既让高光有细节，又让暗部不糊成一团黑。
这里有个常见的认知偏差：很多人以为显示器标称对比度 100000:1 就是 HDR 了。不是。那个数字往往是动态对比度，靠整屏调背光实现的，跟同一帧内的亮度层次完全是两码事。真正决定 HDR 观感的，是同一帧内最亮像素和最暗像素能同时成立的那个区间。
1.2 亮度、对比度与 nits：为什么 HDR 不是"更亮"而是"更宽"
亮度单位用尼特（nit），等于坎德拉每平方米。SDR 的参考白定义在 100 尼特，这是几十年前显像管时代留下的锚点，当年的 CRT 峰值亮度差不多就在这个位置。HDR 的母版参考白通常还是 100 尼特左右（各家规范略有差异），但峰值亮度可以到 1000 尼特甚至 4000 尼特。
打个比方：SDR 像一条两车道的高速路，限速 100，所有车都得在这个速度附近跑；HDR 不是把限速提到 1000，而是把路拓宽成八车道，慢车可以慢到 20，快车可以跑到 1000，而且它们能在同一条路上共存。多出来的是"可用的余地"，不是"整体的亮度"。
这个区别直接决定了创作上的差异。SDR 画面里，一个窗户高光如果超过 100 尼特就必然被削平，处理办法通常是压曝光或者上柔光，让整个画面往中间调靠。HDR 里你可以让窗外的天空顶到 800 尼特，同时让人脸保持 40 尼特，两者的层次都在。所以 HDR 真正带来的不是"刺眼"，而是高光有内容、暗部有余量。
跟亮度相关的还有两个字段，做转码的人必须认识：MaxCLL（最大内容亮度）和MaxFALL（最大帧平均亮度）。前者是整个片子里单像素能达到的最高亮度，后者是所有帧里平均亮度最高的那一帧的数值。这两个数值写在码流元数据里，播放器和电视会读它们来决定怎么映射。这两个值标错了，轻则画面偏暗，重则高光直接被削掉一块，后面第 5 章会具体讲怎么排查。
2. 三大技术支柱：色域、传递函数与位深
HDR 不是一个单独的参数，它是色域、传递函数、位深三件事捆在一起的一整套定义。任何一件没跟上，剩下的都会出问题。我给新人解释的时候喜欢用"颜料、尺子、刻度"来类比：色域决定你能用哪些颜色，传递函数决定亮度怎么被编码成数字，位深决定这把尺子上有多少个刻度。
2.1 色域：Rec.709、DCI-P3、Rec.2020 到底差在哪
SDR 时代的通用色域是BT.709，它的三角形在色度图上画出来不算大，覆盖了可见色域的一部分。电影放映用的是DCI-P3，三角形比 709 宽，尤其在红色和绿色方向多出一截。而 HDR 规范里挂的容器是BT.2020，三角形比 P3 还要再大一圈。
但这里有个行业内公开的秘密：绝大多数 HDR 母版实际的色彩内容并没有填满 BT.2020。原因很现实——能完整覆盖 2020 的监视器和摄影机都极贵，所以实际制作中常见的做法是"容器用 2020，内容按 P3 D65 来做"。这就意味着你在转码时如果无脑按 2020 到 709 做矩阵转换，会得到一个偏艳、偏绿的结果，因为源信号本来就没那么多颜色。
色域转换最怕的是负值和溢出。把宽色域矩阵乘到窄色域上，超出目标范围的颜色会变成负值，如果直接截断，画面里那些高饱和的红花、霓虹灯、荧光绿就会突然失去层次，变成一块死色。正确做法是在线性空间里做转换，把超出部分通过压缩或者映射拉回边界内，而不是硬切。
实操上我给的建议是：先确认源素材实际用到的色域范围，再决定转换策略。可以用一段彩条素材在监视器上看，如果 BT.2020 转 709 之后红色块内部出现明显的断层和色相偏移，说明源里有大量超界颜色，需要走软映射；如果几乎看不出差别，说明源本来就接近 P3，直接矩阵转换就够。
2.2 传递函数：Gamma、PQ、HLG 的分工
传递函数（Transfer Function）解决的是"亮度值怎么变成电信号数字"的问题。人眼对暗部的敏感度远高于亮部，所以如果用线性方式编码，暗部会丢掉大量细节。SDR 用的是伽马曲线，常见 2.2 和 2.4，广播标准里还有一条按显示器特性定义的参考曲线，本质上都是"把暗部抬高、亮部压平"的幂函数。
HDR 里有两条完全不同的路线：
PQ（感知量化，标准号 SMPTE ST 2084）是一条绝对亮度曲线。它把 0 到 10000 尼特这个范围用固定的编码映射下来，也就是说码流里的某个数值永远对应某个确定的亮度，跟显示设备无关。这带来的好处是创作端和显示端有共同语言——调色师在监视器上看到的 400 尼特，观众电视上也会尽量还原到 400 尼特（在设备能力范围内）。代价是它对显示设备的峰值亮度有要求，设备达不到就得做映射。
HLG（混合对数伽马）是一条相对亮度曲线。它不规定绝对亮度，而是定义"相对显示峰值"的关系，同时前半段用类似伽马的曲线、后半段用对数曲线，这样一条信号既能被 HDR 电视正确解读，也能被 SDR 电视"凑合看"，不会一放就灰。这是它被广播系统青睐的核心原因。
我经常用尺子来比喻这两者：PQ 是一把印着绝对刻度的钢尺，量出来是几厘米就是几厘米；HLG 是一把弹性尺，刻度是相对的，你得先告诉它"总长是多少"才能读出具体值。所以在处理 HLG 素材时，必须先确认它的标称峰值亮度（常见 1000 尼特）和系统伽马，不然映射出来一定不对。
| 传递函数 | 亮度定义 | 典型峰值 | 常见场景 | 转 SDR 的难点 |
|---|---|---|---|---|
| Gamma 2.2 / 2.4 | 相对 | 100 nit 参考白 | SDR 播出、网络视频 | 无 |
| PQ（ST 2084） | 绝对 | 1000 / 4000 nit | HDR10、HDR10+、部分商业格式 | 需先线性化再做色调映射 |
| HLG | 相对 | 标称 1000 nit | 广播、直播、部分手机拍摄 | 需先按 OOTF 还原再映射 |
2.3 位深与色度采样：10bit 到底解决了什么
位深决定亮度能用多少个台阶来表示。8bit 是 256 级，10bit 是 1024 级，12bit 是 4096 级。在 SDR 的伽马曲线下，8bit 勉强够用，因为曲线把大部分码值分配给了暗部和人眼敏感的区域，亮部台阶粗一点看不出来。
但 PQ 曲线不一样，它的编码方式在暗部只分配了很少的码值。同样是 8bit，PQ 编码下暗部可能只有十几级台阶，一拉伸就是明显的色带。这就是为什么HDR 几乎强制要求 10bit 起步，而且很多调色环节会建议用 12bit 或者浮点中间格式来处理。
这里有个实际例子：我做一条夜景素材的 HDR 到 SDR 转换，源是 10bit PQ，如果中间过程转到 8bit 处理再转回来，天空渐变那一段立刻出现一圈一圈的同心圆。换成 16bit 整数或者 32bit 浮点中间格式，同样的流程，色带完全消失。所以转码链路上，中间格式的位深比最终输出的位深更值得关注。
色度采样是另一件事，它决定色彩信息的分辨率。4:4:4 是每个像素都有独立的色彩信息，4:2:2 是水平方向两个像素共享一组色彩，4:2:0 是 2x2 四个像素共享。人眼对色度的敏感度低于亮度，所以交付端用 4:2:0 压缩是常规操作。但中间处理和调色环节尽量走 4:4:4，尤其是做键控、抠像、大幅度色相偏移的时候，4:2:0 的色彩分辨率不足会让边缘出现彩边。
| 参数 | SDR 常见配置 | HDR 常见配置 | 说明 |
|---|---|---|---|
| 色域 | BT.709 | BT.2020 容器 | 实际内容常限制在 P3 D65 |
| 传递函数 | Gamma 2.2 / 2.4 | PQ 或 HLG | 决定亮度编码方式 |
| 位深 | 8bit | 10bit 起 | PQ 暗部码值紧张，10bit 是底线 |
| 色度采样 | 4:2:0 | 4:2:0 交付 / 4:4:4 中间 | 母版和调色链路尽量 4:4:4 |
| 参考白 | 100 nit | 100 nit 左右 | 峰值可到 1000 / 4000 nit |
3. HDR 的几种流派：从静态元数据到动态元数据
搞清楚三根柱子之后，再看市面上那几种 HDR 格式，就不容易被缩写绕晕了。它们的核心差异其实只有两点：元数据是静态还是动态，以及兼容策略是绝对亮度还是相对亮度。
3.1 静态元数据：HDR10 的通用底座
HDR10是目前兼容性最好的基础格式。它用 PQ 曲线、10bit、BT.2020 容器，加上一组静态元数据：母版显示设备的峰值亮度、最小亮度、原色坐标，以及前面提到的 MaxCLL 和 MaxFALL。
"静态"的意思是整部片子共用一套元数据，播放器拿到这组数字之后，从头到尾用同一套映射策略。好处是实现简单、兼容性广，几乎所有的 HDR 电视和播放器都支持；坏处是它不够精细——一部片子里有白天外景也有夜晚室内，静态元数据只能取一个折中的峰值，遇到特别亮的场景可能削顶，遇到暗场景又浪费了显示设备的动态余量。
我在实际项目里的体会是：HDR10 的元数据标得准不准，比用什么高级格式更影响最终观感。见过太多片子 MaxCLL 随手填个 1000 就交出去了，实际内容峰值只有 400，结果播放器按 1000 做映射，整个画面被压暗一档，暗部全糊。
3.2 动态元数据：逐场景甚至逐帧做优化
为了解决静态元数据的粗糙，就有了动态元数据方案。代表是HDR10+和几套商业闭环格式。它们的思路是给每一个场景（甚至每一帧）单独标注亮度分布信息，显示端按当前场景的实际峰值做映射，理论上能更充分地利用设备能力。
另一类商业格式走的是更"闭环"的路子：从母版制作、编码、传输到显示端解码，全链路都有专门的授权和认证，映射算法由格式方统一控制，好处是不同设备上的一致性更好，坏处是制作端和播放端都要付出额外的成本和兼容代价。
这类格式落地时最需要注意的是回退机制。动态元数据的片子如果在不支持该格式的设备上播放，必须能正确回退到 HDR10 基础层，再不行回退到 SDR。我做交付的时候一定会准备三个版本：主格式版、HDR10 兼容版、SDR 版，然后在一台老电视、一台新电视、一个手机、一个电脑播放器上分别过一遍。这一步花不了多少时间，但能省掉后面大量的返工。
3.3 HLG：为广播而生的兼容方案
HLG 的设计目标跟前两者不太一样，它一开始就是冲着"一套信号同时服务 HDR 和 SDR 接收端"去的。它的曲线前半段接近伽马、后半段是对数，配合一个系统光光转换函数（OOTF，系统伽马通常取 1.2），使得同一条信号在 SDR 电视上显示时只是对比度略平，不会出现 PQ 那种"不映射就发灰"的问题。
这个特性让 HLG 在直播和广播领域非常吃香——卫星、有线、地面波这些传输链路里，你没法保证每个用户的终端都支持 HDR，HLG 相当于给了一个平滑过渡的方案。
| 格式 | 元数据类型 | 亮度体系 | 兼容性 | 典型用途 |
|---|---|---|---|---|
| HDR10 | 静态 | PQ 绝对 | 极广 | 流媒体、蓝光、网络分发 |
| HDR10+ | 动态 | PQ 绝对 | 需设备支持 | 流媒体 |
| 商业闭环格式 | 动态 | PQ 绝对 | 需认证设备 | 高端影视分发 |
| HLG | 无（或极简） | 相对 | 极广，可直落 SDR | 广播、直播、手机拍摄 |
有一件事值得单独提：手机拍摄的 HDR 视频大多走 HLG 或者某种兼容曲线。这类素材拿到专业软件里处理时，最容易被当成普通 SDR 处理，导致颜色发灰、对比度变平。判断方法很简单，看文件的传输函数标记，如果是 HLG 或者类似标识，就得按 HLG 的规则先做还原。
4. 实操：从 HDR 母版到 SDR 交付的完整链路
概念讲完，落到手上。这一节我按实际操作的顺序走一遍，从一个 HDR 文件开始，到产出一个能看的 SDR 文件结束。中间会给出参数选择的依据和可以直接抄的命令。
4.1 先摸清素材：元数据核查与信号确认
动手之前必须先搞清楚三件事：源文件的色域、传递函数、位深，以及元数据里标了什么。很多人跳过这步直接转码，出来有问题再回头查，时间全浪费在试错上。
我习惯用 ffprobe 先看流信息：
ffprobe -v error -select_streams v:0 \ -show_entries stream=codec_name,width,height,pix_fmt,color_space,color_transfer,color_primaries,color_range \ -of default=noprint_wrappers=1 input.mkv重点看四个字段：color_primaries（色域，bt2020 还是 bt709）、color_transfer（传递函数，smpte2084 是 PQ，arib-std-b67 是 HLG）、color_space（矩阵，bt2020nc 表示非恒定亮度）、pix_fmt（像素格式，yuv420p10le 表示 10bit）。
再看元数据：
ffprobe -v error -select_streams v:0 -show_frames \ -read_intervals "%+#1" -of json input.mkv | grep -A 12 side_data输出里会包含母版显示信息和内容亮度信息两组数据。如果这两组数据缺失，说明这个文件的元数据不完整，播放器只能靠猜，结果不可控。
除了看文件，还要看画面。我一般会把第一帧和几个关键场景截出来，在支持 HDR 的监视器上过一遍，记下三个数字：画面里最亮的部分目测大概多少尼特、最暗的部分有没有细节、整体平均亮度偏亮还是偏暗。这三个数字直接决定后面色调映射的策略。这一步没有捷径，靠的是多看积累的手感。
注意：在普通 SDR 显示器上直接看 HDR 文件，画面会发灰发暗，这是正常的，不是文件坏了。判断内容是否正确，一定要在支持 HDR 的环境下看，或者用带映射的播放器。
4.2 色调映射的核心参数与命令写法
从 PQ 到 SDR 的核心动作叫色调映射（Tone Mapping），本质是把 0 到 1000 尼特甚至更高的亮度范围，压缩到 0 到 100 尼特的显示范围里，同时尽量保住高光细节和中间调的对比关系。
这一步有三个关键参数要想清楚：
第一，目标峰值亮度（npl，nominal peak luminance）。转 SDR 时一般设为 100，对应 SDR 的参考白。如果目标平台偏亮（比如某些网络平台的播放环境），可以适当提到 120 到 150，但要谨慎，提太多会让整体画面失去 SDR 应有的对比感。
第二，映射曲线。常见的有几种：简单的 Reinhard 类曲线压缩比较温和但高光容易发灰；Hable 曲线对高光的处理更硬朗，适合有大面积高光的素材；BT.2390 那条建议曲线在广播领域用得最多，兼顾了高光滚降和中间调保真。我个人的选择习惯是：有大量天空、雪景、灯光直射的素材走 Hable 或者 BT.2390，人像为主、中间调丰富的素材走更温和的曲线。
第三，色域映射策略。从 BT.2020 转到 BT.709 时，超出 709 范围的颜色需要压缩。完全不做处理会出现死色，压得太狠会出现整体褪色。常用的做法是在线性空间里做饱和度衰减，参数一般给 0.3 到 0.6 之间，具体看素材里高饱和颜色的占比。
以常见的开源转码工具为例，一条可用的命令大致是这样：
ffmpeg -i input_hdr.mkv \ -vf "zscale=t=linear:npl=100,format=gbrpf32le,\ zscale=p=bt709,\ tonemap=tonemap=hable:desat=0.4,\ zscale=t=bt709:m=bt709:r=tv,\ format=yuv420p" \ -c:v libx264 -crf 16 -preset slow -an output_sdr.mp4拆开看每一步在做什么：
zscale=t=linear:npl=100：先把 PQ 曲线线性化，同时告诉它目标峰值是 100 尼特。这一步是整个流程的地基，跳过它后面的映射全是错的。format=gbrpf32le：转成 32 位浮点的 RGB 空间，给后面的运算留足精度，防止色带。zscale=p=bt709：把色域从 2020 转到 709。注意这一步只是改了原色坐标定义，还没做超界压缩。tonemap=tonemap=hable:desat=0.4：核心的色调映射，desat控制高光区域的饱和度衰减，避免高光变成一块死白。zscale=t=bt709:m=bt709:r=tv：把线性信号重新编码成伽马 2.4 左右的目标曲线，同时设定矩阵和范围。format=yuv420p：转成最终交付的像素格式。
另一条路线是用基于 GPU 着色器的滤镜，它的映射算法更现代，对色域和亮度的处理是联合优化的：
ffmpeg -i input_hdr.mkv \ -vf "libplacebo=tonemapping=bt.2390:color_primaries=bt709:color_trc=bt709:colorspace=bt709:range=tv" \ -c:v libx264 -crf 16 -preset slow -an output_sdr.mp4这条命令的可读性更好，但具体参数名会随版本变化，用之前先跑一次ffmpeg -h filter=libplacebo确认一下当前版本支持的写法，别直接复制粘贴到老版本上。
提示：
crf 16是我在 SDR 交付里常用的保守值，配合preset slow能保证暗部渐变不出块。如果只是做预览，crf 20、preset medium足够，速度快好几倍。
4.3 色域映射与最终封装检查
转完之后绝对不能直接交付，必须做三项检查。
第一项，标记是否正确写入。用前面那条 ffprobe 命令再看一遍输出文件，确认color_primaries=bt709、color_transfer=bt709、color_space=bt709、color_range=tv。这四个字段只要有一个不对，播放器就会按错误的假设去解释信号，画面立刻偏色或者发灰。我遇到过最隐蔽的一次是color_range被写成了pc，结果整片黑位被抬起来，暗部一片灰雾，查了两个小时才发现是封装参数的问题。
第二项，关键帧的目视比对。把源 HDR 在支持映射的播放器里放一遍，把输出 SDR 在标准显示器上放一遍，截同一帧并排看。重点看三个地方：高光区域（天空、灯、水面反光）有没有丢掉层次、中间调（人脸、皮肤）的色相有没有偏移、暗部（阴影、黑衣服）有没有被压死或者浮起来。这项工作听起来玄，但只要做过十几条片子，眼睛会形成基准，一眼就能看出问题。
第三项，多设备验证。至少在一台电视、一台电脑、一部手机上各放一遍。不同设备的映射算法差异很大，同一份文件在电脑上刚好，在电视上可能被二次映射得偏暗。这一步能帮你发现元数据标注的兼容性问题。
还有一个容易被忽略的点：音频和字幕的封装。做视频转换时经常只关注画面，结果音轨的响度标准、字幕的时间轴在重新封装后出问题。我的习惯是视频和音频分开处理，最后用封装工具合并，并且在合并后再抽查一遍音画同步。
5. 常见问题与排查实录
这一节是我这些年踩坑攒下来的清单。HDR 转 SDR 出的问题，九成以上能归到下面这几类，按症状对号入座，基本能快速定位。
5.1 画面发灰、发暗、过曝的区分与定位
同样是"画面不对"，成因完全不同，处理方式也完全不同。第一步要做的是准确描述症状，而不是笼统地说"颜色不对"。
| 症状 | 最可能的原因 | 验证方法 | 处理方式 |
|---|---|---|---|
| 整体发灰、对比度低、黑位浮起 | 把 PQ 信号当伽马信号直接解码 | 看是否跳过了线性化步骤 | 补上 PQ 到线性的转换 |
| 整体偏暗、高光死白 | 映射时目标峰值设得过低，或 MaxCLL 标注过大 | 检查 npl 参数和元数据 | 调整目标峰值，修正元数据 |
| 暗部一片死黑 | 映射曲线过陡，或黑位裁切过度 | 对比源文件暗部细节 | 换更温和的曲线，保留黑位 |
| 高饱和颜色断层、色块 | 色域转换时硬截断负值 | 看红花、霓虹灯区域 | 改用软压缩映射 |
| 暗部出现同心圆色带 | 中间处理位深不足 | 检查中间格式位深 | 改用 16bit 整数或浮点 |
| 肤色偏绿或偏洋红 | 色域矩阵用错，或白点不一致 | 检查色域和白点标记 | 统一到 D65 再做转换 |
这张表我贴在显示器边上用了很久。举一个具体例子：有一次转一批素材，输出画面整体发灰，第一反应是映射曲线选错了，换了三种曲线都没改善。后来回头查流程，发现线性化那一步的参数被漏掉了，等于在伽马空间里直接做映射，所有亮度关系都是错的。补上那一个参数，问题立刻消失。这类问题的共性是有明确的因果链，不要靠反复试参数去碰运气，要按流程一段一段回查。
5.2 兼容性与元数据丢失：那些"在我电脑上好好的"问题
第二类高频问题是兼容性。同一个文件，在剪辑软件里正常，导出来在手机上放就偏色；在自己电脑上正常，到客户那儿就发暗。这类问题的根源基本都是元数据在某一环被丢掉了。
元数据丢失最常见的三个环节：
一是剪辑软件导出时没有勾选色彩标记。很多软件的默认设置是"不写入色彩元数据"，文件本身数值是对的，但播放器不知道该怎么解释，只能按默认的 SDR 处理。
二是中间格式转换时被剥离。某些封装容器在转码过程中会丢掉帧级的附加信息，尤其是静态元数据那两块。解决办法是尽量用支持完整元数据的封装格式，或者在转码命令里显式指定。
三是播放器自身的处理策略。有的播放器在检测到 HDR 信号但显示设备不支持时，会直接做一次粗暴的裁剪，而不是软映射，结果就是高光一片死白。这不是文件的问题，但用户看到的就是"你的片子有问题"。
我的应对办法是把验证环节前置：在项目开始时就确定交付规范，包括容器格式、编码参数、元数据字段、以及目标播放环境，然后拿一段测试素材走一遍全流程，确认每一环都正常之后再批量处理。这个习惯看起来麻烦，但比起交付后被退回来重做，成本低太多。
5.3 几条踩坑心得
最后说几条不太容易从文档里学到的东西。
第一条，别迷信自动映射。现在很多软件都有"一键 HDR 转 SDR"，效果在简单素材上还行，遇到大光比或者高饱和场景就会露馅。自动算法的目标通常是"不出大错"，而交付需要的是"关键镜头好看"。我的做法是自动跑一遍做基准，然后针对重点镜头手动调，尤其是人脸和产品特写。
第二条，暗部比高光更难处理。大部分人转 HDR 时盯着天空看，其实最容易出问题的是暗部。PQ 曲线在暗部码值本来就紧张，映射时稍不留神就压成一片黑。判断标准很简单：把画面亮度调高看暗部，如果细节还在，说明保留了；如果全是纯黑块，就是压死了。
第三条，留一份可回溯的母版。我所有的转换都保留原始文件和完整的参数记录，包括命令行、软件版本、映射曲线、目标峰值。原因很实际：客户半年后说"当时那个版本更好看"，你得能复现出来。参数记在本子上容易丢，我习惯直接写在项目文件夹的说明文件里，跟着素材一起归档。
第四条，用灰阶和色卡做基准测试。每次换新设备、新软件版本，先拿一段灰阶渐变和一张标准色卡跑一遍，看看暗部有没有断层、高光有没有削顶、各色块的色相有没有偏移。这个动作五分钟，能提前发现大部分环境问题。我自己就因为这个习惯，在一次软件升级后及时发现了映射算法的默认参数变了，避免了整批素材返工。
第五条，别在错误的显示器上做判断。用 SDR 显示器看 HDR 素材，或者用没校准的屏幕判断颜色，得出的结论全是错的。如果条件有限，至少保证判断"信号是否正确"时用支持 HDR 的环境，判断"颜色是否准确"时用校准过的 SDR 环境，两件事分开做，不要混在一起下结论。
这套东西说到底，HDR 和 SDR 的差别不在于参数表上多几个数字，而在于整条链路上每个环节都得知道自己在处理什么信号。我见过太多项目卡在"看起来不对但说不出哪里不对"的阶段，最后发现都是某一环的元数据或者某一步转换被想当然地跳过了。把色域、传递函数、位深这三根柱子记牢，再养成先查元数据再动手的习惯，大部分问题在发生之前就能避开。
