4.5 The write side and derived IDs

Writing is planned, not improvised. For each outgoing attribute the planner decides: write it, derive it, omit it, or suppress it — and can say why for each. The ID selection sequence for colorInteropID runs:

flowchart LR
    A["declared by the config<br/>(interop_id, OCIO 2.5+)"] --> B["derived by transform comparison<br/>against the built-in identities"]
    B --> C["matched by name or alias"]
    C --> D["generated config-local ID<br/>(collision-guarded)"]
    D --> E["none hold:<br/>omit — never guess"]

A genuine transform match outranks a name match — behavior is better evidence than spelling. Two more rules keep files clean: internal working attributes never reach a file (they are stripped at the writer boundary), and confirmatory metadata (CICP, chromaticities, gamma) is co-written where the format supports it, so consumers that have never heard of colorInteropID lose nothing. In the demo, write_plan(spec, "exr") returns the full per-attribute plan with reasons.

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

Or straight from GitHub, nothing cloned:

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