Q100362：优化 GPU 加速颜色管理的自定义 OCIO 配置

概括

本文介绍了Mari 3.3v1 中对 OCIO 颜色管理系统所做的更改，并详细介绍了如何通过为每个颜色空间创建颜色转换覆盖来充分利用这一新的 GPU 加速系统进行自定义颜色配置。

注意：本文面向经常使用自己的自定义 OCIO 配置的工作室，并且可能会引用家庭用户不熟悉的术语。

更多信息

Mari 3.0引入了 OCIO 色彩管理系统，该系统支持强大的流水线色彩管理工作流程。这通过源图像、各个通道和 GPU 工作空间的色彩空间属性提供了更好的控制。 OCIO 系统消除了对任何色彩空间的源图像进行预处理或对导出图像进行后处理的繁琐要求。

Mari的所有图像处理都是通过 GPU 上的 GLSL 着色器执行的。然而，OCIO 提供的色彩空间转换类型非常有限。例如，它当前不支持条件分支，并且在大多数情况下使用 LUT 来执行颜色空间变换。

当在 GPU 上使用时，LUT 变换作为 3D 纹理提供，不幸的是，它可能会遇到性能和准确性问题。这些 3D 纹理的样本数较低，因此如果用于将绘制缓冲区烘焙到可绘制图层，则会损失浮点精度。为了确保最终颜色数据的准确性， Mari通过使用原始 OCIO 数学在 CPU 上执行扫描线渲染来解决这个问题。这种增加的开销降低了Mari的整体性能。

在Mari 3.3中， nuke默认颜色管理配置数学被转换为原生 GLSL 着色器代码。将颜色转换从 CPU 切换到 GPU 显着提高了Mari中的油漆烘烤性能。还公开了用于注册自定义着色器代码的 API 函数，以取代使用 CPU 扫描线方法渲染自定义着色器的需要。

为了充分利用这个新的 GPU 加速颜色管理系统来进行自定义颜色配置，您需要为每个颜色空间到颜色空间创建颜色转换覆盖。这包括从本机色彩空间到工作色彩空间的转换，以及Mari中使用的每个色彩空间之间的转换。

您需要做什么

为了正确说明Mari中所做的色彩空间调整，以下是Mari在将 sRGB 参考图像烘焙到设置为 ACEScg 的通道中的可绘制图层（当工作色彩空间也设置为 ACEScg 时）所采取的步骤：

1. 源图片
   （实用程序 - sRGB - 纹理）
2. 将源绘画转换为工作色彩空间
   （实用程序 - sRGB - 纹理 -> ACES - ACEScg）
3. 将现有目标绘画转换为工作色彩空间
   (ACES - ACEScg - > ACES - ACEScg) （无变化）
4. 显示交互式Paint Through工具并执行烘焙操作
   (ACES-ACEScg)
5. 将烘焙油漆转换为目标通道色彩空间
   （ACES - ACEScg -> ACES - ACEScg） （无变化）
6. 最终通道数据
   (ACES-ACEScg)

注意：如果工作色彩空间配置为附加色彩空间，则在上面提到的（无变化）步骤中将发生附加色彩空间转换，并且这些也需要被覆盖。

为了确保为您的自定义颜色配置正确实现颜色空间转换覆盖，您需要考虑管道中的以下三个不同角色：

1. 色彩科学家
   计算每个色彩空间 A 到 B 和 B 到 A 转换的数学。
2. 着色器编写器
   将颜色数学编码为每个变换的优化 GLSL 着色器代码。
3. 管道探明
   要构建色彩空间变换，需要对每个变换进行注册，并在艺术家启动Mari时执行它们。

例子

本文随附可供下载，您将找到我们的示例代码，说明如何针对Mari 4.0v1 中的 ACES 1.0.3 配置优化这些更改。这些Python文件的内容可以在脚本编辑器中执行，或者可以将文件放置在您的Mari Scripts目录中，以便在Mari启动时自动执行。您可以在以下位置找到Mari Scripts 文件夹：

Linux 和 OS X： ~/ Mari /Scripts
Windows ： C:\Users\<username>\Documents\Mari\Scripts

您将在附件中找到以下两个文件：

register_which_transforms.py

运行时，该文件将遍历您当前的项目并定义需要加速的所有色彩空间转换。然后，这会打印出项目数据以及在 Python 控制台中注册色彩空间转换覆盖所需的 Python 命令。这将标有 \TODO 语句。

register_aces_shader_transforms.py

该脚本解释了我们为优化 ACES 1.0.3 配置文件而进行的转换注册。该文件还包括一个调试选项，该选项会将 sRGB - ACEScg 变换变为绿色以提高可见性。