ACES AP0 还会溢色？
- Color
- 三十分钟系列
ACES AP0 还会溢色？
ACES 色彩处理流程为什么会溢色？
稍微了解ACES 的人都会知道定义了两个色彩空间：
AP0 （2065-1）AP1
在色域映射 这篇文章中说到了溢色的问题，由于Arri Wide Gamut 的色域有一些超过了AP1 的范围，这样就会导致后续的算法出现一些裁切，从而最终在显示上呈现出“溢色”。
这个问题我们可以归结于AP1 的色域不够大，如果用AP0 是不是就不会发生溢色了呢？
从xy 色度图中可以看出，AP0 的定义的确覆盖了所有正常人可以看到的色彩，理论上应该不会再出现色域不够大导致的溢色。
但是再实际的制作中，其实AP0 也是导致溢色的一部分因素。
为了明确问题出在哪里，我们先回顾一下ACES 色彩管理的基本过程：
如果明白原理的小伙伴可能就发现其中的端倪了：
提示
只要转换前的色彩空间不是完全包含在转换后的色彩空间内，那么就有可能出现超色域（out of gamut）的情况。
而这种情况正是“溢色” 的本质原因。
那么这个过程中会有几个出现超色域的可能？
- 使用
IDT，从摄影机的编码色彩空间转换到AP0的过程 - 从
AP0转换到AP1的过程 - 从
AP0转换显示色域的过程
本文只讨论第一种情况。
第二种情况可以参看色域映射。
第三种涉及到Scene 到 Display 的转换，有机会以后再说。
为什么ACES AP0 还会溢色？
针对第一种情况，有的小伙伴可能会问：
纳闷
AP0 不是都已经覆盖了所有人眼可见的色彩么，那为什么还会在IDT 转换的时候出现超色域的问题？
如果你肯再仔细阅读一遍这个问题，会发现这个问题本身就包含了答案！
关键点就是：“AP0 覆盖了所有人眼可见的色彩”。
而IDT 的作用是，将摄影机的编码色彩空间转换到AP0。
摄影机可不是人眼哦！
也就是说，摄影机可能记录了人眼看不到的颜色（当然也存在摄影机记录不下来人眼能够看到的色彩的情况）。
我们还是拿图片说话，下面的图中包含了市面上常见摄影机的编码色彩空间的色域范围，可以看到他们都不是完全包含在AP0 的色域范围内。
引用来源： ACES Working Group Proposal by Matthias Scharfenberg & Carol Payne
这时候你会有一个直观的感觉：
如果一个三角形A 不是完全在另一个三角形B中，那么在A -> B 的转换就会出现超色域的问题。
但是这到底是为什么？我们可以更加仔细的来看一下。
三个超能力者抢球的故事
我们先来想像一下:
如果有R、G、B三个超能力者站成一个三角形，他们都可以通过原力来吸引一个小球。
如果认为每个人原力的发力范围是 0~1，三个人分别使出不同的程度的原力。
那么请问小球可以分布的范围是什么？
（我们这里做个限制，那就是三个人合在一起的力量必须=1，>1会爆炸，<1 会塌陷！）
只有某一个人发全力的情况
也就是一个人发力 1.0，另外两个人都完全不发力 0.0。
很明显，小球会被吸引到发全力的那个超能力者手中。
(R, G, B) = (1.0, 0.0, 0.0)
(R, G, B) = (0.0, 1.0, 0.0)
(R, G, B) = (0.0, 0.0, 1.0)
只有两个人发力的情况
也就是另一个人完全不发力.
记住，我们有个限制，就是三个超能力者的合力必须=1，也就是说R + G + B = 1.0。
这就好像是两个人在较劲，谁出力大一些，另一个人出力就会小一些，那么小球的位置一定出现在这两个人之间的。
(R, G, B) = (r, g, 0.0)
(R, G, B) = (0.0, g, b)
(R, G, B) = (r, 0.0, b)
三个人都发力的情况
那么可以想象成三个人在争抢这个小球，小球最后可能出现在三角形内的任何一个位置上。
也就是说三角形内的任何位置都可以通过三个人不同的发力组合来表达：
提示
对于三角形内部的任何位置，都可以通过r, g, b三个不同的系数进行组合。
这三个系数满足下列条件：
- 0 ≤ r ≤1，并且 0 ≤ g ≤ 1，并且 0 ≤ b ≤1
- r + g + b = 1
(R, G, B) = (r, g, b)
如何将小球移动到三角形外面
这时候，出现了一个神奇的情况！有一个位置在三角形的外面，三个能力者还必须通过某种发力组合，将小球移动到那个位置上，这怎么办？
根据上面的结论，如果不改变现状，三个超能力者不论怎么组合发力，都不可能将小球移动到三角形外。
这时候有人说了我们是不是可以稍微打破一点规则？
既然前面说的三人合力必须=1 这条规则不能打破的话，那么我们就打破每个人发力只能在 0~1 之间的这个规则吧！
如果有人能够发力 < 0，那么就相当于不是吸引力，而是反向的“推力”了，那么这时候，就可以实现把小球“推”出三角形了！
这种情况下，r、g、b 三个发力系数中必定会有负数的存在！
而这个负数，就是后续造成溢色问题的开始。
想象这个三角形就是AP0，而小球现在的位置就是属于摄影机编码色彩空间中的某个位置，那么这个小球对于AP0 来说就是超色域的存在。
负数的麻烦
在数学的计算中，负数本身的没有任何问题的。但是当我们将这个转换赋予真实的物理含义时，负数就变得有些棘手了……
在直观的色彩感受中：
- 如果
亮度 = 0，可以认为是无光（黑） - 如果
亮度 = 1，可以认为是最亮（白） - 如果
亮度在 0~1 之间，可以认为是某个灰度
但是 亮度 < 0，是个负数，那么这是个什么亮度？比黑更黑？还是物极必反，变成超级亮？
同理，如果一个红色的强度 < 0，那么这是个什么颜色？比无色更无色？还是红色的补色，变成青色？
大部分的算法在解决这些负数的时候，为了保证“安全”+“简单”，都使用了比较粗暴的裁切算法，也就把所有 < 0 的数值都变成0。
这么一个操作的确解决了不少问题，但是副作用的产物之一就是“溢色”。
如何解决AP0 溢色的问题？
回到文章的主题上，想要解决AP0 的溢色，那么最直观的方案就是把AP0 的色域变得超级大！可以包含任何一种摄影机编码色彩空间的范围，这样就搞定了！你可真是个小机灵鬼儿！
扩大 AP0的色域
如果你决定使用这个方法，那么在实际工作中马上就会出现两个问题：
- 多大算大？
- 如果现在修改了
AP0的定义，那么之前的软件的兼容性怎么办？
现在你觉得数字摄影机编码空间最大的，应该RED Wide Gamut，那么我们重新定义AP0 的时候，就比这个色域在大一圈吧！
好的，现在肯定没问题，甚至说未来的一段时间也没有问题，但是谁都难说会不会再出现更大色域的摄影机编码色彩空间？到时候岂不是这个问题就又会出现。
人类都会受制于当下的认知。
比尔盖茨曾经的名言
“个人电脑的内存只需要 640K 即可，没有人需要超过这个数”。
也可能有人说，那就把AP0 定义到不合理的大！比方说能够包含 xy 色度图中 ~ 这么大的数值范围！
嗯，的确够大，而且估计也没有什么摄影机会吃饱了撑的，搞个比你更大的色域范围。
但是这又出现了一个编码利用率的问题，大部分的可见颜色都分布在xy 色度图 0~1 这个范围内，也就是说，你的编码利用率可能极低。
回想上面的三个超能力者，现在他们站的非常远，但是小球可能出现的范围只是很小的一个范围，那么三个人出力的组合也总是在一个很小的范围内。
而且，还会连带引发出数值精度的问题。
好吧，现在退一步，假设你找到了一个“合适大小”的色域空间，又会面临第二个问题。
毕竟ACES AP0 已经是一个公开的标准，无数的软件、算法、插件都是基于这个标准实现的。
这时候，你说我要更新AP0 的定义，这就相当于捣毁了摩天大楼的地基，上面所有的架构都需要重新来过。
你以为很简单，只要来个V2.0 这样的新标准就好？千万不要低估人类的习惯和惰性，你想想 winXP 活了多少年，才不情愿的被win7、win10 取代？
那么ACES 官方是怎么解决的？
呃，其实ACES 官方也没有想好……所以他们建立了Virtual Working Group （VWG）来讨论到底应该怎么办。
至少有了一些可能的解决方向：
- 提出一个对于数字摄影机更合适的编码色彩空间
- 提出一个合适的
working 色彩空间 - 提出一个合适的
色域映射算法（GMA），这个算法可以适用于广色域、HDR、scene-referred 色彩空间。并且是可逆的。
所有的这些努力都是为了ACESNext 可以实现更好的色彩管理流程！
没准下一代ACES 就会自带新的能力，解决现阶段摄影机溢色的问题啦！
