...

Application-specific Roles

Details.

Undefined Roles

Details.

Standard Roles

Details.

Scene Save Behavior

DetailsApplications should use standard roles for appropriate color space assignment when possible. If a role for a specific use case in the app doesn’t exist, the app should support an app-specific custom role. App-specific roles should adhere to the naming convention:

<app name>_<use/task> (e.g. “mari_blending”).

App-specific roles should default to inheriting their color space from a standard role. This default should be clearly documented in a role table. Example: https://learn.foundry.com/mari/Content/user_guide/managing_colors/color_management.html

Undefined Roles

If a config does not define a given role, it is an indication to the application that it may ask the user to select one of the color spaces from the config.  Typically a config authored by a facility color scientist for a specific show will chose a specific role, but generic configs (e.g. those produced by the OCIO working group) may omit the roles in cases where there is more than one viable solution depending on the details of a specific workflow.

Standard Roles

Standard roles should be used in the following way:

• default: When using color space rules to determine a default color space, OCIO will use this role if no other space can be determined. It does not need to be referenced by an app directly.
• reference: This role has had multiple interpreted meanings over the years and is a common point of confusion. It is kept in OCIO for backwards compatibility, but the recommendation is that it is not used by apps.
• data: A no-op color space which bypasses any color management. This should be the default for utility image data (normals, position, displacement, alpha, etc.).
• color_picking: This role has been another point of confusion, used in various different ways historically. The recommendation is that it be used to define the gamut of colors that can be picked (limiting, but not necessarily clamping), but that the picked colors themselves are represented and stored in the app’s working space (e.g. scene_linear). It is also recommended that color picker gradients and swatches support the option to be viewed through the current display and view (output transform), allowing artists to target display colors in addition to scene colors.
• scene_linear: The default linear working space. Apps should generally do all internal processing of linear image data in this space. This may or may not match the reference role. For example, the reference role may point to ACES2065-1 while scene_linear points to ACEScg. Or they could both point to ACES2065-1.
• compositing_log: Color space to use for compositing operations which operate on logarithmically encoded image data (e.g. rolloff or filters with negative lobes). This can also be used with the scene_linear role for default log-to-lin and lin-to-log conversion when the specific spaces are less critical than their general characteristics.
• color_timing: Color space for logarithmic color grading operations, also commonly used to define the working space for look application, matching on-set grading pipelines.
• texture_paint: Working color space for texture painting, which may be a display-referred space like sRGB or a linear space like ACEScg. This is highly dependent on the pipeline, but is commonly used for diffuse (albedo) textures so in many cases is limited to a [0.0, 1.0] domain.
• matte_paint: Working color space for matte painting, which may be a display-referred space like sRGB or a logarithmic space for utilizing high dynamic range data in applications which operate in unsigned integer data types.
• rendering: This color space will typically match scene_linear, but may differ for color pipelines that are rendering in a studio-defined linear color space while compositing in a different client-defined linear color space. For example, a studio may adhere to ACES, but finish shots in ALEXA wide gamut if shots are being delivered in that space to clients.
• aces_interchange: If defined this will always refer to a color space implementing ACES2065-1, used exclusively for interchange between two different OCIO configs (between scene referred spaces). This is internally used by OCIO so does not need to be referenced by an app directly.
• cie_xyz_d65_interchange: If defined this will always refer to a color space implementing CIE XYZ with a D65 white point, used exclusively for interchange between two different OCIO configs (between display referred spaces). This is internally used by OCIO so does not need to be referenced by an app directly.

Scene Save Behavior

When an app is saving a scene, role color space selections should be saved to the scene file as the color space they point to (their “canonical” color space name) instead of the role name. If the role then changes there will be no visual impact when loading the scene later. The exception to this rule is when storing global color space preferences with no direct impact on visual results of the scene. For example, an app may have a preference that defines a role or color space to use when importing new images into the scene. That could be saved as a role name so that the desired behavior is consistent after an OCIO config change. However, if an already imported image has been assigned a color space with a role name, it should be saved as the color space name, so that an OCIO config change will not alter the scene’s rendered result.

Mockups (optional)