SUMMARY
This article explains the changes made to the OCIO Color Management System in Mari 3.3v1 and details how to fully utilise this new GPU accelerated system for custom color configurations by creating color transformation overrides for each colorspace.
NOTE: This article is targeted for studios who work regularly with their own custom OCIO configurations and may reference terms that are unfamiliar for home users.
MORE INFORMATION
Mari 3.0 introduced the OCIO color management system which allowed powerful and pipelined color management workflows. This offered greater control via colorspace properties on source images, individual channels and the GPU working space. The OCIO system removed the laborious requirement of pre-processing source images or post processing exported images for any colorspace.
All of Mari’s image processing is performed with GLSL shaders on the GPU. However, OCIO is quite limited in the types of colorspace transforms it provides. For example, it does not currently support conditional branching, and in most cases a LUT is used to perform the colorspace transform.
When used on the GPU, a LUT transform is provided as a 3D texture which can unfortunately suffer from both performance and accuracy issues. These 3D textures have a low sample count and therefore lose floating point precision if used to bake the Paint Buffer to paintable layers. In order to ensure accuracy in the final color data, Mari works around this by performing a scanline render on the CPU using the raw OCIO math. This added overhead decreased Mari's overall performance.
With Mari 3.3, the nuke-default color management configuration math was converted into native GLSL shader code. Switching the color transformation over from the CPU to the GPU dramatically improved paint baking performance in Mari. An API function to register custom shader code was also exposed to replace the need to render custom shaders with a CPU scanline method.
In order to fully utilise this new GPU accelerated color management system for your custom color configuration, you will need to create color transformation overrides for each colorspace to colorspace. This includes transformations from native colorspace to working colorspace and back, as well as the transformations between each colorspace used in Mari.
WHAT YOU WILL NEED TO DO
To properly illustrate the colorspace adjustments made in Mari, here are the steps that Mari takes when baking a sRGB reference image down into a paintable layer in a Channel set to ACEScg, when the working color-space is also set to ACEScg:
- Source image
(Utility - sRGB - Texture) - Convert source paint to working colorspace
(Utility - sRGB - Texture -> ACES - ACEScg) - Convert existing target paint to working colorspace
(ACES - ACEScg - > ACES - ACEScg) (no-change) - Display interactive Paint Through tool and perform bake operation
(ACES - ACEScg) - Convert baked paint to target Channel colorspace
(ACES - ACEScg -> ACES - ACEScg) (no-change) - Final Channel data
(ACES - ACEScg)
NOTE: If the working colorspace was configured to an additional colorspace, then an additional colorspace transformations would occur at the steps where there is (no-change) noted above and these would also need to be covered.
In order to ensure that colorspace transformation overrides are correctly implemented for your custom color configuration, you will need to consider the following three different roles within your pipeline:
- Colour Scientist
To work out the math for each colorspace A to B and B to A conversion. - Shader Writer
To encode the color math into optimised GLSL shader code for each transform. - Pipeline TD
To construct the colorspace transform registration calls for each transform and execute them when artists launch Mari.
EXAMPLE
Attached to this article and ready to download, you will find our example code of how these changes were optimised for the ACES 1.0.3 config in Mari 4.0v1. The contents of these Python files can be executed in the Python Console palette, or the file can be placed in your Mari Scripts directory for automatic execution at Mari startup. Your Mari Scripts folder can be found at the following location:
Linux and OS X: ~/Mari/Scripts
Windows: C:\Users\<username>\Documents\Mari\Scripts
Attached you will find the following two files:
register_which_transforms.py
When run, this file will walk through your current project and define all of the colorspace transformations required to be accelerated. This then prints out the project data, and the Python commands required to register colorspace transform overrides in the Python Console. This will be labelled with \TODO statements.register_aces_shader_transforms.py
This script explains the transformation registrations we took to optimise the ACES 1.0.3 config file. This file also includes a debug option that will turn the sRGB - ACEScg transform green for visibility.
We're sorry to hear that
Please tell us why