Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Use Cases

...

  • A config author defines standard OCIO roles and studio-specific custom roles for each config so that pipeline software can provide consistent behavior across projects without awareness of how they differ in their underlying color management choices.
  • An application provides several app-specific roles allowing a config author to tune the application's color management preferences per config without code or user intervention.
  • A studio uses clearly named roles to guide artists in an application toward color spaces for specific tasks without needing an understanding of color science terminology.
  • A studio uses an interchange role to convert images from a past project to a new project without concern for color pipeline differences between them.
  • An application uses an interchange role to map color between a proprietary camera SDK and their OCIO implementation without knowledge of the config's contents.

Guidelines

App Developers

Color Space Menus

...

When an application is saving a scene, role 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 should 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)

...