5. Compatibility

Delegation, backfill, stability

Delegation and backfill

The design implements the function set the Forum’s ColorInteropID recommendation describes for OCIO-based applications. Where the linked OpenColorIO provides a function natively — getInteropID (2.5+), IdentifyBuiltinColorSpace, GetProcessorFromConfigs (2.2+) — it delegates to OpenColorIO. Where the function is recommendation-described but not yet in a release — findColorSpaceForID, generateLocalIDForColorSpace, LocateBuiltinColorSpace — it backfills the described semantics, and hands off to the native implementations as they arrive. That is the compatibility posture in one sentence: OpenColorIO 2.2+ all works, newer OpenColorIO simply works more natively. This repository’s helper does exactly the same feature-detection in pure Python, which is why it runs identically against OpenColorIO 2.2 and 2.5.

Stability

Identification results must not drift between builds. The identities data is pinned per release and compiled in byte-for-byte, so every build of a given release agrees exactly on the built-in ID list; transform comparison runs with optimizations off under a documented tolerance, so a space identified as lin_ap1_scene today is identified as lin_ap1_scene on every platform tomorrow. Config-local IDs are, by design, derived from the user’s own config name — stable for the same reason. And the never-guess floor is itself a stability guarantee: the system’s honest “I don’t know” never silently becomes somebody’s wrong answer downstream.

Config adoption is optional and incremental

No config changes are required for any of this to work. One line (aces_interchange) anchors a config for exact conversion and identification; a config name: plus published-ID aliases buys name-tier resolution on every OpenColorIO version; a declared interop_id: (OpenColorIO 2.5+) wins outright. Each step is independent, and each buys a little more.