DOCSEARCHbyAlgolia
Submit Docs

OpenColorIO (OCIO) Documentation

repository·main·Indexed 24 days ago

https://github.com/academysoftwarefoundation/opencolorio

An industry-standard color management solution for motion picture production, VFX, and animation. Written in C++ with a Python API, OCIO ensures consistent color appearance across software tools and hardware. It is compatible with the Academy Color Encoding Specification (ACES), supports various LUT formats, and is natively integrated into applications like Katana, Mari, Nuke, Maya, and Houdini. The project includes ocioview, a config visual editor application (v0.1.0).

Tokens
53.3K
Snippets
62
Records
300
Agent score
82%

What's inside OpenColorIO

  1. What is OpenColorIO (OCIO)?

    main

    OpenColorIO (OCIO) is a color management solution designed for motion picture production, specifically visual effects and computer animation. It provides a consistent user experience across different applications while allowing for sophisticated back-end configurations.

    Key characteristics:

    • Compatibility: Compatible with the Academy Color Encoding Specification (ACES).
    • Format Agnostic: Supports many popular LUT formats.
    • Implementation: Written in C++ with a Python API.
    • Mechanism: OCIO's color science is driven by transforms defined in a YAML configuration file. By specifying a config file in the local environment, all OCIO-compatible applications and libraries can access the same defined color transform "universe."

  2. Overview of OpenColorIO (OCIO)

    main

    OpenColorIO (OCIO) is a complete color management solution designed for motion picture production, specifically targeting visual effects (VFX) and computer animation. It provides a consistent user experience across different applications while supporting sophisticated back-end configurations.

    Key features include:

    • Standard Compatibility: Compatible with the Academy Color Encoding Specification (ACES).
    • Format Agnostic: Supports many popular LUT (Look-Up Table) formats.
    • Cross-Platform: Designed to be stable and performant on Linux, macOS, and Windows.
    • Industry Support: Natively supported in major commercial applications such as Katana, Mari, Nuke, Maya, Houdini, and Silhouette FX.

  4. Use OpenColorIO Application Helpers for application development

    main

    OCIO v2 provides a collection of helper utilities located in src/OpenColorIO/apphelpers designed to simplify common application development tasks related to color management. These helpers assist with:

    • Color Space Menus: Building hierarchical menus that support filtering by category.
    • Viewing Pipelines: Constructing viewing pipelines for application viewports, including support for dynamic exposure adjustment.
    • Color Pickers: Implementing color pickers that correctly handle scene-linear color encodings.
    • Config Modification: Programmatically adding new color spaces or views to an existing OCIO configuration file.

  5. Compatible Software for OpenColorIO

    main

    OpenColorIO is supported by a wide range of professional visual effects, animation, and color grading software. Below is a list of compatible applications and their supported versions:

    • RV (Autodesk): Version >= 4
    • Silhouette (Boris FX): Version >= 4.5 (Native integration for import/export and display)
    • Substance Designer (Adobe): Version >= 2019.3
    • TouchDesigner (Derivative): Supported via OpenColorIO TOP
    • Unreal Engine (Epic Games): Version >= 4.22
    • Vegas Pro (Magix): Version >= 12 (Supports workflows like S-log via ACES)
    • V-Ray (Chaos Group): Supported via OpenColorIO and VRayTexOCIO
    • VRED (Autodesk): Version >= 2025.3

  6. Use CLF test files and source images for implementation testing

    main

    The CLF test kit provided in this directory includes:

    • CLF_testImage.exr: A source target image that samples the full domain of half-float values.
    • CLF test files: A collection of files used for testing. The recommended collection is located in the OCIO unit tests directory: tests/data/files/clf/*.
    • Reference images: Images generated by processing the source image through the test CLFs.

    These resources are intended to aid in the development and validation of Academy/ASC Common LUT Format (CLF) implementations.

  7. What is a Look and how does it work?

    main

    A Look is an optional color transform defined in the OCIO config, similar to a colorspace but used for specific artistic or technical grading (e.g., a "first pass DI beauty grade").

    When an application applies a Look, OCIO follows a specific pipeline to ensure the grade is applied in the correct colorspace:

    1. Convert the image from its current input colorspace to the Look's defined process_space.
    2. Apply the Look's transform within that process_space.
    3. Convert the resulting image from the process_space to the desired output colorspace.

    To define a Look, you must specify:

    • name: A unique identifier for the look.
    • process_space: The colorspace in which the transform is performed.
    • transform: The actual color transformation to apply.
    • inverse_transform (Optional): Required for transforms that are not trivially invertible, such as 3D LUTs. If a look is applied in reverse and no inverse_transform is provided, OCIO will return an error.
    looks:
  - !<Look>
    name: beauty
    process_space: lnf
    transform: !<CDLTransform> {slope: [1, 2, 1]}

  8. What is an OCIO Look and how does it differ from a colorspace?

    main

    A look is a named color transform intended for creative modifications (e.g., a neutral grade or a director's DI grade), whereas a colorspace is typically a technical or mathematical definition.

    Unlike colorspaces, a look requires a defined process space—the specific colorspace in which the transform is applied. When a look is applied, the input pixels are converted to the look's process_space before the transform is executed.

  9. Understand Reference Art and Display spaces (vd8, vd16, vdf, hd10)

    main

    These spaces map linear image data into display space.

    • vd8, vd16, vdf: Mappings of linear data into display space. The transformation conceptually combines a ln to lg conversion with an lg to sRGB conversion. The dynamic range is limited to ~2.5 stops above diffuse white to prevent high-end linear values from creating unintended deltas in 8-bit images. This makes them suitable for matte paintings.
    • vdf: Specifically used when receiving video space encoded EXRs; it only defines the transformation from 0-1.
    • hd10: A vd-based space used for importing/exporting REC709 range broadcast material. It scales data via a matrix operation to limit the range from 64-940 before applying the standard vd transformation.

  10. Understand OpenColorIO core terminology

    main

    OpenColorIO (OCIO) uses a specific set of terms to describe color management workflows. Understanding these definitions is essential for configuring transforms and managing color pipelines:

    • Transform: A function that alters RGB(A) data (e.g., transforming an image from scene linear to sRGB).
    • Colorspace: A meaningful color space that can be transferred to and from a reference space.
    • Reference space: A central space that acts as a connection point between different colorspaces.
    • Display: A virtual or physical display device (e.g., an sRGB display device).
    • View: A meaningful view of the reference space on a Display (e.g., a film emulation view on an sRGB display device).
    • Role: An abstract colorspace naming convention used to map specific colorspaces to functional purposes (e.g., assigning the lnh colorspace to the scene_linear role, or using a color_picking role for a UI color picker).
    • Look: A color transform that applies a creative intent (e.g., a per-shot neutral grade to remove color casts or a Digital Intermediate (DI) look).

  12. Use Roles to simplify color space selection

    main

    A role is an alias for a color space that allows applications to perform task-specific transforms without requiring the user to know the exact color space name. For example, a 'compositing_log' role allows a node to always use the correct log space defined by the project.

    Commonly used roles:

    • aces_interchange: The ACES2065-1 color space for inter-config conversion.
    • cie_xyz_d65_interchange: Standard CIE XYZ colorimetry (D65).
    • color_picking: Space used for color selection UIs.
    • color_timing: Space used for applying color corrections/grades.
    • compositing_log: A log space used for processing (e.g., Nuke's OCIOLogConvert).
    • data: Used for non-color data (normals, depth); should typically have data: true set in the color space definition.
    • default: Fallback space when strictparsing is false.
    • matte_paint: Space for matte painting.
    • reference: The reference color space against which others are defined.
    • scene_linear: The scene-referred linear-to-light color space.
    • texture_paint: Space for painting 3D textures.
    roles:
  color_picking: cpf
  color_timing: lg10
  compositing_log: lgf
  data: ncf
  default: ncf
  matte_paint: vd8
  reference: lnf
  scene_linear: lnf
  texture_paint: dt16