OpenColorIO lists native support inside Disguise and Unreal Engine

The stage

OpenColorIO is a living project rather than a dated release, so the record here is its documentation as retrieved on 16 September 2026. OpenColorIO's project site describes itself as a complete color management solution geared towards motion picture production with an emphasis on visual effects and computer animation, currently at version 2.5.0, with recent additions including full ACES 2.0 support and Vulkan GPU rendering. The project's GitHub repository, hosted under the Academy Software Foundation, states the framework has been in development since 2003, tracing its lineage through films including Spider-Man 2 and Alice in Wonderland, compatible with the Academy Color Encoding Specification and agnostic to LUT format.

What the documents establish

OpenColorIO's supported-applications listing is a checkable claim, not marketing copy: it names version thresholds for native integration, including Disguise Designer from r29.1 and Unreal Engine from 4.22, among dozens of tools. That is OCIO's documentation describing which applications built native support, not a claim by Disguise or Epic about their own products, and the distinction matters because a virtual-production pipeline spans a render engine, a media server and a camera's working color space built by different vendors. What the documents jointly establish is narrower than a claim that OCIO is the VP color standard: one open, ASWF-hosted framework has documented native support inside a leading media-server platform and engine, a precondition for a shared color pipeline, not proof any stage has adopted it.

The department view

The color pipeline sits with the DIT and on-set colorist, who need the engine's output, the wall's calibrated color and the camera's working space to agree closely enough that what the camera records matches intent. Without a shared framework, that agreement is negotiated ad hoc through vendor-specific LUTs generated separately for the engine and wall's processor. OCIO's documented role is to let a config file define those transforms once and have supporting applications honor it, a shared configuration problem instead of a per-vendor one. The undocumented trade-off is governance: someone still has to own and version that config across every application in the chain.

What to check before you build

This is editorial guidance beyond what OCIO states. A DIT should confirm the engine, media server and camera tools in use meet OCIO's native-support thresholds; that the config deployed on set matches the one validated in preproduction, since a mismatch produces a color error easy to miss; and that any ACES-based component uses the ACES version OCIO's release documents.

• Which applications in our pipeline meet OCIO's documented native-support version threshold today?
• Who owns the OCIO config across preproduction, the volume and post, and how is a change tracked?
• Does our ACES version match across the render engine, the wall's processor and the DI pipeline?

An open, foundation-hosted color framework does not make color management automatic; it makes a shared configuration possible across vendors that would otherwise each define color their own way. OpenColorIO's reach into a widely used media-server platform and engine is a genuine interoperability data point, best treated as an option to configure and verify, not a default any volume already has correctly deployed.