Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

WORK IN PROGRESS

Background

OCIO v2 introduced several new mechanisms for reducing the clutter of color space menus in applications. Previously, all color spaces would be visible in most app menus, which can mean hundreds of options in some configs, and an overwhelming experience for users without careful organization of color spaces into families. This was particularly problematic for config authors introducing utility or deprecated color spaces, which were not intended to be selected by users directly, but needed to be present for the color pipeline to function. They could be hidden away in clearly named family menus, but remained available for errant selection.

One of the new mechanisms introduced in OCIO v2 is the concept of color space visibility, specifically supporting active and inactive color spaces. An inactive color space remains present in the config for use in color processing by an implementation, but is hidden from menus by default. An app developer can request active or inactive color spaces from the config, and the inactive color spaces defined by the config can be overridden by a user via an environment variable.

Note: A matching active/inactive mechanism applies to named transforms, also introduced in OCIO v2.

Resources

Use Cases

  • A config author adds one or more legacy color spaces to a config which must be present for reusing elements from older productions, but should not be used for new elements.
  • A config contains multiple utility color spaces or named transforms which are strictly for use internally by pipeline tools, but should be hidden from menus.
  • A particular studio pipeline tool needs to limit the available color spaces in a way which does not intersect defined color space categories, so defines OCIO_INACTIVE_COLORSPACES with a list of color spaces which should not be available in its menus.

Guidelines

App Developers

Intent

Inactive color spaces are intentionally inactive, which implies they are deprecated or for internal use only. An application developer does not have to check if a color space is inactive since the Config API will not return inactive color spaces unless explicitly requested. If a previously active color spaces is now inactive, but still referenced in the app's parameters, it will continue to function as expected when constructing processors, despite being omitted from default queries.

Color spaces can be made inactive by a user through the OCIO_INACTIVE_COLORSPACES environment variable, which defines a comma delimited list of color space names, overridding the base definition in the config.

Menus

Inactive color spaces should not be included in any menus, and are not returned by the config by default when parsing available color spaces. There is one exception to this rule, where an application should manually add an inactive color space to a menu, as outlined in the case below.

Since inactive color spaces are still valid in a processor, existing use of these spaces should be preserved in an application. If a menu selection already references an inactive space in a scene file, the selection should be preserved. Apps can test the validity of a seemingly undefined color space via Config::getColorSpace(name), and if using OCIO's color space menu helper, add that space to a menu with ColorSpaceMenuHelper::addColorSpace(name). The added (inactive) color space should be included as the topmost item in the menu, optionally with an trailing indicator that it is inactive like “(inactive)”.

  • No labels