4.4 Transform-comparison identification

The backbone of backward compatibility. A config written years before colorInteropID existed has spaces named things like “Studio Linear” and no ID anywhere. Identification recognizes such a space by what it does: build the transform from the space to the interchange anchor (aces_interchange), probe it, and compare the numeric behavior against the built-in identities in the registry. If “Studio Linear” transforms identically to ACEScg, it is lin_ap1_scene — no config edit required. Comparison runs with optimizations off and a documented tolerance, so results are reproducible across builds and platforms, and they are memoized on the config cacheID so the cost is paid once per config.

The crucial restraint: identification produces a derived ID, always distinguished from a declared one, and when the numbers match nothing in the registry, the answer is “undetermined” — not the nearest neighbor. Deriving is documented, explicit behavior, never a silent relabeling of the user’s space.

NoteLayering note

Matching a space by its chromaticities, by its transfer characteristic, or by full transform comparison is config introspection more than file I/O. OpenImageIO backfills this today; it is a natural candidate for OpenColorIO itself, and OpenImageIO’s design delegates natively as OpenColorIO grows the capability (as it already does for IdentifyBuiltinColorSpace where available).

TipRun it
just edit 04                                            # from a checkout
uvx marimo run --sandbox notebooks/04_identification.py

Or straight from GitHub, nothing cloned:

uvx marimo run --sandbox https://raw.githubusercontent.com/zachlewis/color_interop_demo/main/notebooks/04_identification.py