OpenColorIO's config backwards compatibility is the product

Colour management for pipelines, not for one application

OpenColorIO is described as a complete colour management solution aimed at motion picture production, with an emphasis on visual effects and computer animation. The design goal is stated as a pair: a straightforward and consistent user experience across all supporting applications, and sophisticated back-end configuration options suitable for high-end production usage. That pairing is the reason the library exists rather than a colour picker in a DCC tool. One surface, so a compositor and a lighting artist see the same behaviour, and a configuration layer underneath, so a studio can define its own spaces, looks and displays once. It is compatible with the Academy Color Encoding Specification, and it is LUT-format agnostic, which matters because the alternative is a pipeline where the choice of LUT file format constrains which tools you can use. Development began in 2003, and the README ties it to specific productions from SpiderMan 2 through Cloudy with a Chance of Meatballs and Alice in Wonderland. It is natively supported in Katana, Mari, Nuke, Maya, Houdini and Silhouette FX, so for most studios the question is not whether you will use it but how much of your own configuration you will write.

Config backwards compatibility is a mission item

The project's own list of aims is the most useful documentation in the README, and one line stands out: maintain config backwards compatibility across major versions. In a studio that means a show that started six years ago can still open its colour configuration after the library has been upgraded twice. The rest of the list explains what that promise costs. Stability, security and thorough testing across Linux, macOS and Windows; performance on modern CPUs and GPUs; compatibility with critical colour and imaging standards; lossless colour processing wherever possible; and a requirement that every new feature be carefully reviewed by people from motion picture, VFX, animation and video game backgrounds. That last item is why the version numbers move slowly and why the repository carries GOVERNANCE.md, a SonarCloud quality gate badge, a CII Best Practices badge and separate continuous integration for GPUs, analysis and wheels. If your decision criteria are novelty, this project will look conservative. If your criteria are that an image rendered in 2010 still matches today, that conservatism is the feature.

Reference configs live in another repository, versioned by name

The configurations that make the library useful are not in the main repository. Reference OCIO configuration files and their associated LUTs are published in the Imageworks OpenColorIO-Configs repository, and the README lists the reference implementations it knows about. From Sony Pictures Imageworks there are two, spi-anim and spi-vfx. From the Academy Color Encoding System there are five versioned ones, aces_1.0.3, aces_1.0.2, aces_1.0.1, aces_0.7.1 and aces_0.1.1, and there is also a nuke-default. Newer built-in ACES configuration files come from the releases section of a separate OpenColorIO-Config-ACES repository. The versioned names are the point. A configuration is a document that a studio depends on for years, so it needs its own identity and its own history, separate from the library version, and the presence of aces_0.1.1 next to aces_1.0.3 says the project expects a production to stay on the colour decisions it started with. The practical consequence for an adopter is that pinning OCIO is only half the job: your config is a second, independently versioned dependency, and a fork of a reference config is a fork you now maintain.

The Python package learns its version by running CMake

The Python distribution is not a separate version string that has to be kept in step by hand. setup.py, which the header says is adapted from the pybind cmake example, contains a get_version function that runs CMake in a temporary directory and reads the version out of a header CMake generated:

subprocess.check_call(["cmake", here], cwd=tmpdir)
path = os.path.join(tmpdir, "include", "OpenColorIO", "ColorSpaceABI.h")

A regular expression then pulls the full version string out of that file, and a missing value raises rather than defaulting, so a broken build fails loudly. The same file contains a cmake_find_package helper, which writes a throwaway CMakeLists.txt containing a find_package call marked required, runs CMake, and reports whether the package was found. That is a pragmatic way to answer dependency questions from Python without a second source of truth. The build metadata also shows what a build pulls in: setuptools, wheel, CMake 3.14 or newer, and Ninja, with Ninja excluded on win32 and on arm64 machines. Installation details are in INSTALL.md at the repository root, and the build requirements themselves are more informative than the instructions for understanding what you are installing.

Every wheel is validated by ociocheck

The packaging configuration for binary wheels contains a test command, and it is two things:

test-command = [
    "python {project}/tests/python/OpenColorIOTestSuite.py",
    "ociocheck"
]

The first is the project's own Python test suite, and the second is ociocheck, the tool that exercises the library's own view of a colour configuration. Shipping a colour library through a wheel without running the checker would mean shipping a build that may transform correctly and still describe a display incorrectly, which is the failure mode that costs a studio a day of grading. The configuration also declares numpy as a test requirement and sets build verbosity, with a per-platform before-build step that installs the documentation environment on Linux, macOS and Windows, which is why the documentation build is part of the wheel pipeline rather than a separate concern. The practical takeaway is that pip install on a machine with no GPU is enough to validate an installation, because the same checks run on every published wheel.

macOS 10.15, and no Ninja on arm64

Two platform details in the wheel configuration are worth knowing before you file a packaging bug. On macOS, the comment says cibuildwheel in some cases defaults the deployment target to 10.9 while OCIO needs 10.15 or newer, and that macOS ARM wheels need 11.0, with the environment variable set so the tool bumps it where appropriate. On Windows, the documentation path is prepended so the tools can find Doxygen during the build. The Ninja exclusion is the quieter one: the build requirement list marks ninja as conditional on the platform not being win32 and the machine architecture not being arm64, so a Linux arm64 or Windows build resolves a different set of build tools than a desktop Linux build. None of this is exotic, and all of it is the cost of a C++ library with wheels for three platforms. The wider set of process signals in the README, with separate badges for continuous integration, GPU tests, analysis, the quality gate and the wheels, is the honest summary of what a project at this level of adoption maintains.

BSD-3-Clause, many copyright holders, and named maintainers

The licence is BSD-3-Clause, which for a library that commercial applications embed is close to frictionless, and the repository carries both a LICENSE file and a THIRD-PARTY.md for the portions imported from other projects. The copyright model deserves a sentence of its own, because the README explains it directly: the statement used throughout the project is a contributors copyright rather than a single company, files often carry multiple copyright holders, and the specific origin of a piece of code can be traced through the git history. The history behind that is named too. OpenColorIO was originally developed and open sourced by Sony Pictures Imageworks, who wrote the core design and the majority of the 1.0 code and continue to support 2.0. The design and development of 2.0 is led by Autodesk, who submitted a proposal to revitalise the project in 2017 and have authored most of the 2.0 code since, with significant contributions also from Industrial Light and Magic and DNEG. For anyone deciding where the standard is going, that paragraph is the answer, and it is more informative than a roadmap.

Against the host's own colour tools, and against a chain of LUTs

There are two alternatives, and they fail in different ways. The first is using only what your application ships, which is the cheapest option and works perfectly for a single application with media that never leaves it. It breaks the moment a shot crosses between tools, because each tool then has its own idea of what a display or a log space is, and the mismatch appears as a shot that looks right in one application and wrong in the next. The second is a chain of baked LUTs, which is what most pipelines were built on before this library existed. A LUT chain has no names, so there is nothing to configure, and nothing to explain why two shots differ. OCIO replaces that implicit list with named colour spaces, a view and display layer, and transforms between them, which is why the reference configurations ship as documents with versions. ACES is a related standard rather than a competitor: the README describes OCIO as compatible with the Academy Color Encoding Specification, and the aces configs are shipped as reference implementations, so adopting one implies the other rather than replacing it.

Editorial conclusion

Adopt OpenColorIO if your pipeline spans more than one application or more than one show, because the config file is the contract and the project's stated goal is that it keeps loading across major versions. Do not adopt it for a single-application job where the host's built-in colour management already round-trips your media, since you would be taking on a configuration surface for nothing. Verify four things before you standardise on it: that the reference config you intend to base on, spi-vfx, spi-anim, an aces_1.0.x or nuke-default, is one you can live with rather than one you will fork, since forking a reference config is how compatibility guarantees stop applying to you, that the Python wheel for your interpreter exists and installs, that ociocheck runs in your continuous integration rather than only on a workstation, and which release you pin, given v2.5.0 on 2025-10-01, v2.5.1 on 2026-01-13 and v2.5.2 on 2026-05-13 with the last push on 2026-09-28.

Frequently asked questions

Official sources

1. AcademySoftwareFoundation/OpenColorIO on GitHub
2. License: BSD-3-Clause
3. Project website
4. README
5. Releases