更新与提示
2026.09.22，Vivo 正式公开了 Vivo Log 和 Gamut 的技术规格，还有新的还原 LUT 和开放的 DCTL，可以从这个链接下载到。
后文中关于 Vivo Log “不开放” 的相关内容均已过时，仅供读者参考，为此，更新了标题以避免歧义。
官方的技术规格完整披露了 Vivo Log 的公式，Vivo Wide Gamut 的色坐标，本文中的数值在精度范围内能够与之匹配。官方本次更新的不加密的 DCTL 内容与先前的 DCTLe 是不同的，不能比较，所有的数值请以官方披露的为准。
以下内容未经改动
犹抱琵琶半遮面
Vivo 从 X200 Ultra 开始宣扬视频能力，尤其是专业领域的能力。比如说能拍 Log，能进 ACES 工作流等等。但相比其他手机提供白皮书，LUT，DCTL IDT “三件套”，Vivo 的 Log 资料提供少得格格不入。
https://zhan.vivo.com.cn/experience/wk240909115effe4
这个奇怪的域名是 Vivo Log 的还原 LUT 下载地址，网页标题叫“下载 LUTs”，点进去却是一张大图片描述 ACES 是什么东西，页面底部有一个“下载还原 LUTs”的按钮，除了 LUT 以外，一个加密的 dctle 文件也藏在压缩包里，用于将 Vivo Log 素材转进 ACES AP0 空间。
即便过程这么曲折，网上也有人走通了 Vivo Log 的 ACES 工作流，比如 这篇文章。可谓极具探索精神。
最近的 X500 系列的影像发布会上，Vivo 又把 Log 视频拿出来讲了一遍，提到新开发了 Vivo Wide Gamut 和新的 Log 曲线，难道 X200 和 X300 的 Log 就要在这种遮遮掩掩的状态下被抛弃了吗？
图源自 IT 之家，这个图表的标题叫 CIE 1931 UCS，和 BT.709 比色域面积，有点太不“专业”了。
守得云开见月明
本着拼图和集卡的目的，我很想把所有 Log 都研究一下，至少看看长什么样吧，但 Vivo 一直不开放，先前对 dctle 的研究不太顺利，难道真的没有办法了吗。
就在今天，Davinci 更新了 21.1 版本，竟然增加了对 Vivo Log，Vivo Gamut 等空间的支持。
作为专业软件，只要在 CST 节点上将色域压缩和色调映射设置为无，并控制变量：
- 控制颜色空间不变，将传递函数输入和输出指定为 Vivo Log 和线性。
- 控制传递函数为线性，将颜色空间输入和输出指定为 Vivo Wide Gamut 和 XYZ。
然后导出静帧为 RGB Float 格式的 EXR，就能保留下带有负数的浮点结果。
- 每个像素值的变化是否能被同一个非线性函数描述。
- 每个像素值的变化是否能被一个 3x3 的矩阵乘法描述。
如果拟合的差异小于浮点数的量化误差，就能分别得到 Vivo Log 曲线和 Vivo Wide Gamut 向 XYZ 变换的矩阵，从而获得色坐标。
Vivo Log 曲线
Vivo Log 的曲线形状与大疆的 D-Log 高度相似，也比较类似 Arri 的 LogC3。
最大能够编码约 3783% 反射率，18% 灰对应 39.1%码值，18% 灰以上有 7.7 档左右。
出于排版考虑，保留了三位有效数字，不是具体公式。
Vivo 广色域
Vivo Wide Gamut 的基色坐标如下，是从 RGB 到 XYZ 的矩阵中推出的，保留了四位有效数字。
- R (0.7063, 0.2957)
- G (0.1913, 0.9623)
- B (0.1115, -0.0492)
- W (0.3127, 0.3290)
白点为 D65，相比别的手机用 BT.2020 做 Log 的色域空间，Vivo 这个广色域设计的就更加有自己的想法，将绿色和蓝色都适当移到马蹄图外来换取更多的实际覆盖。
可能从图中会觉得绿色特别靠外，这其实是 CIE 1931 xy 不均匀导致的错觉，比如将其转到 CIE 1976 UCS。
这下变成蓝色特别靠外了，这是因为 1931 到 1976 的影射变换没有考虑这种负值虚拟基色。这也说明对于这种有虚拟基色的空间，比较面积是没有意义的行为。
对比刚才发布会的那张图，会发现这个 Vivo Wide Gamut 好像就是发布会上的那个，并非全新设计。而发布会上的图没有 BT.2020，或许是因为这个空间并不能完全覆盖 BT.2020，所以只放了和 BT.709，P3 的对比。
吹尽狂沙始到金
其实在 Davinci 支持之前，我尝试用类似的流程，利用 Vivo 提供的那个加密的 dctle，当作一个黑盒，不过知道输入是 Vivo Gamut 和 Vivo Log，输出是 AP0 和线性，试图直接拟合这两部分。
很快，就发现这个 dctle 连色适应都没有，相等的 RGB 输入不能获得相等的 RGB 输出，并不是一个合格的 ACES IDT，也就不想在这个黑盒上花更多精力了。
虽然颜色空间不可靠，但 Log 曲线还能勉强拟合，单纯从测试图拟合的话，是无法得到准确的 Log 公式的，我推测它采用了比较流行的线性段加 Log 段，通过调整底数和优化，拟合出了这个结构。
Davinci 正式支持之后，恰逢 DeepSeek V4.1 Flash 更新，我就让它直接对 Davinci 本体做了一些静态的分析，消耗了 23M Token 之后得到了一些确切的数字，填入之前分析出的结构之后，发现能够与 CST 得到的数据对应上。又发现实际的 Vivo Log 相比 dctle 里的版本，整体上有 1.158 倍的缩放关系，不知道是什么原因。
纸上得来终觉浅
对 dctle 的分析更坚定我的一个观点：不公开参数的 Log，作用约等于空气。
如果 Davinci 始终没有支持 Vivo Log，用户只有一个最基本的转 709 的 LUT 和有错误的 dctle 黑盒，没有办法将素材正确还原到场景参考的线性光，无论如何后期操作，拍到的 Log 视频色彩都是错误或没有后期空间的。
开发者和创作者也完全无法给它制作更好的工作流或 LUT，油管上甚至有人提出给 Vivo Log 素材套 LogC3 的 LUT 这种移花接木的做法，幸运的是 Vivo Log 和 LogC3 比较接近，这种做法才显得没那么搞笑。
Log 开发出来是让专业工作者用的，不该成为发布会上产品经理一个吹牛逼的卖点，遮遮掩掩还搞个加密的做法只显得滑稽可笑。
等我再学习一下 DCTL 的语法，会做一个正确的 Vivo Log ACES IDT 来练手。