1.前言

“为什么达芬奇导出的视频颜色变了？”——这不仅是许多使用 MacBook 内建屏调色的独立创作者的噩梦，即便是拥有“上屏卡+监视器”标准流程的职业调色师，也难以逃脱这个灵魂拷问。

一个典型场景为：监视器完美的画面，导出发给制片或客户后，在他们的设备上却发灰或黑色细节丢失；抑或是达芬奇 GUI 与 Clean Feed 画面无法统一。 罪魁祸首是 macOS 的历史悠久的色彩管理机制：ColorSync。其中存在着一些已经过时了的技术标准，这导致了显示输出的时候，码值也许已经被不正确的修改了。

为了解决这个问题，网络上流传着各种“偏方”：从 Reference Mode 到 ICC 配置，从 Rec.709-A 到 Gamma Tag 修改。名词层出不穷，众说纷纭。然而，许多方案虽然勉强实现了“视觉上的一致”，却忽略了实际的显示Gamma，这意味着调色结果并无法和专业的监视器进行匹配。因此无法完全解决交付时的混乱。

这一次，糊师傅决定死磕到底。通过控制变量法，测试了 macOS 环境下几乎所有的输出链路，试图彻底终结这个“老生常谈”的玄学问题。

本次测试覆盖了你可能遇到的所有场景：

• 显示终端： 横向对比 MacBook 内建屏、HDMI 外接显示器、以及通过上屏卡输出的 SDI 监视器；

• 硬件差异： 单独测试了配备 XDR 屏幕（具备 Reference Mode）的新款 MacBook Pro，与普通非 XDR 屏幕机型的差异；

• 播放环境： 对比了 QuickTime、IINA、VLC 三大主流播放器的色彩渲染逻辑；

• 底层机制： 拆解 ICC Profile 的运作原理与 NCLC Tag 的色彩管理机制；

• 解决方案： 提出也许是 SDR 内容制作的最佳实践。

由于篇幅较长且干货过密，本文将拆分为 A篇 与 B篇：

• A篇： 直接展示实验过程以及结果，给出“最佳实践指南”。

• B篇： 详解色彩管线原理，剖析 macOS 色彩管理的底层逻辑。

A篇

完整测试

测试方法：

制作测试序列：

• 完整灰阶： 水平灰阶（便于示波器检查）、纵向灰阶（便于 Side-by-Side 肉眼对比）。

• 关键色块： 8bit 码值下的 0, 4, 8, 16, 24, 32, 127, 235, 255。数据采集：

• 内建屏： 使用 Klein K10-A 探头直接读取绝对亮度。

• 监视器 (HX3110)： 先用探头确认 EOTF 准确，再配合机内示波器确认输出码值。

Q：截屏对比的方案为何不行？A：将不同播放器、窗口显示的同一画面截图对比的方法及并可取，首先其没有考虑到跨显示设备时，设备本身的 EOTF 特性并不相同；其次没有考虑到，截图软件本身在色彩链路中并不是最后一环，这意味着截图获得的码值可能只是某个中间状态而非最终显示效果。这是一种典型的“刻舟求剑”的办法。

Q：为什么不用 Calman 的 GreyScale(Multi)功能自动采集 EOTF 曲线？A： 经过实测，Calman 在调用达芬奇作为 Pattern Generator（信号发生器）时，会跳过一部分达芬奇内部的色彩管理管线，导致测量结果不符合用户的实际使用场景。因此为了还原实际调色的显示色彩链路，在这里选择手动测量。

Q：为什么要对比 v20.0 与 v20.2.3 两个版本？A： 因为 v20.2.3 更新了一个关键选项：Viewers match QuickTime Player when using Rec.709 Scene。我们需要验证开启该选项后，软件行为是否发生了本质变化。

测试数据

由于数据量实在是太庞大、各种选项设置的排列组合过于之多，因此此次测试包含了几种常见的情况。并做成小卡的形式方便检索，其中左侧小卡代表了硬件和设置情况，右侧小卡为该情况下的测试结果。

其中 IINA 关闭 ICC 是指 IINA 播放器的设置中“加载 ICC 配置文件”的选项关闭。

结论

Gamma 2.4 在 Mac 上没有完美方案

经过上述测试，我们不得不接受一个现实：在 macOS 生态下，如果坚持以 Gamma 2.4 为监看和交付标准，目前似乎并不存在一个能兼容所有场景的完美解法。即使使用了上屏卡+监视器的组合进行调色，客户审片、观众观看的时候，看到的画面又会有所偏差。基于本次实验数据，我们可以总结出以下问题：

• 达芬奇 Rec.709-A 非常鸡肋，其本身并未解决什么问题。在大多数情况下，它反而导致我们实际上是在监看一个 Gamma 1.961 的画面。

• 配备 XDR Display 的机型与普通 Mac 在 ColorSync 的处理机制上存在差异。例如，在HDMI输出屏幕上出现的“暗部压缩”现象，在 XDR 机型上并未复现，这增加了统一标准的难度。压缩曲线如下图所示，在 4% 及以下码值出现了一个很明显的压缩。

• VLC 播放器（以及关闭 ICC 后的 IINA）本质上并无色彩管理，其表现接近于“码值直通”。这反而是我们想要的结果！

• Gamma 偏移的主要原因，在于 ColorSync 未能正确应用 1.22 的光光转换函数 (OOTF)。苹果试图通过 1.961 × 1.22 ≈ 2.4 来还原画面，但实际渲染结果往往事与愿违。

• 测试数据显示，ColorSync 在进行显示转换时，似乎有时会引入一个分段函数处理，导致部分场景下出现了明显的暗部压缩（死黑）或非线性抬升。

然而，测试结果却给了我们意外之喜：以 Gamma 2.2 为目标，配合 sRGB 作为达芬奇输出空间，即可实现全链路 “EOTF 大一统”。这应当成为所有 Mac 用户在制作客户审片版或流媒体母版时的首选格式。

互联网交付内容最优解——以sRGB作为输出色彩空间

经过全链路测试，结论非常清晰： 当达芬奇的输出色彩空间选择 sRGB 时，可以保证在几乎所有的显示设备中，都以正确的 Gamma 2.2 曲线进行监看。此时输出的 MOV 文件 NCLC Tag 为 1-13-1，其 EOTF 是完美的 Gamma 2.2。 在这种情况下，ColorSync 的色彩管理机制似乎终于“放过”了视频文件——它绕过了恼人的 Gamma 1.961 转换，也绕过了时有时无的 System Gamma Boost (1.22)。第三方播放器也能“乖乖地”保证码值直通，不再添加额外的处理。以下表格是该理想情况的详细设置：

此时，我们的监看目标已锁定为 Gamma 2.2。 针对不同的色彩管理工作流，具体操作如下：

• 使用 CST (色彩空间转换) 时： 需将 Output Gamma（输出伽马）明确设置为 Gamma 2.2。

• 使用 ACES 工作流时： ODT (输出设备转换) 应选择 sRGB Gamma2.2。

• 使用 LUT 还原时： 若使用了目标为 Rec.709 Gamma 2.4 的 LUT（如官方的 Film Looks 或摄影机还原 LUT），务必在节点树的末尾添加一个 CST 节点，执行 Gamma 2.4 到 Gamma 2.2 的转换。（记得关闭色调映射 Tone Mapping，将其设置为无 None) !!! 注意，这里的“输出伽马”千万不要选择sRGB，因为这里的 sRGB 为分段函数，并不是我们想要的 Gamma 2.2。

以 Gamma2.4 作为最终交付的实践指南

无论如何设置色彩管理的每一个细节，需要从始至终搞清楚：

视频信号里的 RGB 只是冷冰冰的码值 (Code Values)，它们不发光，也不包含“亮度”或“反差”。

只有当这些码值传输给显示设备，并由其按照特定的 EOTF 曲线将其“翻译”为光线时，我们才真正看到了画面。 理想的闭环是：调色师输出什么码值 -> 显示器就严格按设定的 EOTF（如 Gamma 2.4）亮出多少光 -> 交付后的文件在相同的 EOTF 上进行呈现。

Rec.709 Gamma 2.4 已然是 SDR 交付的通用标准。Rec.709 Gamma 2.4 依然是目前 SDR 影视交付的绝对通用标准。 我们在上文中引入 Gamma 2.2 (sRGB)，更多是一种“向下兼容”的防御性策略。我们无法约束客户在什么环境下看片（大概率是明亮的办公室），也无法控制他们用什么设备。在这些不可控因素下，Gamma 2.2 是最安全的“最大公约数”。在正确的码值转换的前提下，用户看到的画面色彩、反差，仍然是与调色师一致的。

为了保证审片一致性，如果你选择全程采用了 sRGB (Gamma 2.2) 环境进行调色，但在最终交付广播级母版时，必须把 Gamma 还原回去。在达芬奇的节点树末尾（或时间线节点上），添加一个 Gamma 2.2 到 Gamma 2.4 的 CST（色彩空间转换）。还要记得关掉 Tone Mapping！

在这里糊师傅还要推荐一个更加专业的审片播放器 VideoVillage Screen。它允许用户手动跳过 bypass macOS 的色彩管理管线。实现码值直通。

关于 HDMI 输出的额外警告

即使我们已经通过 sRGB 方案搞定了 Gamma，但在测试 HDMI 直连外接显示器时，糊师傅还是捉到了一个“漏网之鱼”：

• 现象：同样的画面，HDMI 直出的暗部会出现诡异的绿色偏色（如下图所示：左侧为 Mac HDMI 直出，右侧为上屏卡 SDI 纯净信号）。

• 软解： 虽然使用第三方工具 BetterDisplay 强制关闭 GPU Dithering 后可以消除绿边，但这也再次证明了操作系统对显卡输出的干预是多么防不胜防。

• 关于这个问题的详细分析也将放在 「B篇」，敬请期待。

糊师傅的终极建议： 如果你想彻底断绝这种后顾之忧，我强烈建议物理隔离。 现在去小黄鱼淘一张二手的 BMD UltraStudio 3G Monitor（上屏卡）仅需千元不到。这笔小投资能换来 100% 无干扰的纯码值信号，足以满足绝大多数 1080P/60fps 的调色监看需求。专业的事，还是交给专业的硬件来做。

照着上面的作业抄完，虽然问题解决了，但硬核的你心中或许仍有未解之谜：

• sRGB 的“分段函数”去哪了？ 为什么到了显示端，它就变成了纯纯的 Gamma 2.2？

• 幽灵般的 Gamma 1.961 为何而发明？ 翻遍了标准文档，为何从来没见过这个数值？

• NCLC的第二个 Tag 4 明明是 Gamma 2.2， 为什么实测出来的 EOTF 曲线却完全不对板？

• Tag 明明选对了，实测中那些奇怪的“暗部死黑（压缩）”和“暗部发灰（抬升）”又是从何而来？知其然，更要知其所以然。 所有的这些“反直觉”的真相，以及 macOS 色彩管理的底层黑盒，糊师傅将在 「B篇」 中层层揭秘。

然而，内容交付之后，观众看到的画面真的和我们在创作端看到的一致吗？这背后不仅涉及不同显示终端的硬件特性，还牵扯到不同浏览器、播放 APP 的色彩管理机制，甚至包括各大视频平台是否会对视频码值进行“二次矫正”。这个坑实在太深了……至于这些更复杂的交付端问题，也许在未来的「C篇」和「D篇」中，糊师傅再来慢慢填补。

--未完待续--