Name the responsibility before naming the file
OCIO, ACES, and ASC CDL can appear in one production, but they are not interchangeable. OpenColorIO is a configurable color-management system: its display/view documentation describes views that transform scene-referred reference data for a display color space, with optional look transforms. ACES defines a framework of input and output transforms; its input-transform documentation describes conversion from a camera/device encoding to ACES relative exposure values.
ASC CDL is a compact creative correction exchange convention, commonly used for slope, offset, power, and saturation decisions. It can describe a look, but it does not declare the entire input color encoding, display/viewing transform, or LED calibration. Do not store a CDL next to a shot and call it “the color pipeline.” Instead, register the domain it is meant to affect and the assumptions it makes.
Make one row per transform or look
| Register field | Illustrative entry | Purpose |
|---|---|---|
| Kind | OCIO config / ACES input transform / CDL / output view | Prevents category confusion. |
| From → to | camera log → ACES; scene-linear → review display | Declares direction and domain. |
| Identifier/version | Config hash, transform ID, CDL filename | Makes the decision reproducible. |
| Owner and approval | Color pipeline lead; dailies approved | Separates technical custody from creative sign-off. |
| Applies to | Show, sequence, shot, or review monitor | Stops a local look being misapplied globally. |
Keep input, look, and output distinct
For an ACES workflow, an input transform takes camera/device material into an ACES representation; an output transform makes scene-referred ACES suitable for a specific output/display condition. The ACES output-transform documentation says that this output step includes rendering and display encoding components. A creative CDL may be placed at an agreed stage in a workflow, but its position must be recorded; applying the same values before and after a major rendering transform is not necessarily equivalent.
Illustrative example: a shot register has a camera input transform, an ACES/OCIO working configuration, a dailies view, a shot CDL approved for dailies, and a separate LED-stage calibration reference. The CDL belongs to the shot look. The display view belongs to review. The calibration reference belongs to the stage chain. The entries may influence one another, but they must not overwrite each other’s purpose.
Validate with a round trip and named view
- Open representative material in each receiving application with the declared config and view.
- Verify that the named input, look, and output are actually selected—not merely installed.
- Compare a controlled reference and a representative creative frame through the intended review path.
- Log deviations, temporary overrides, and any baked transforms in the delivery.
This is a documentation method, not a replacement for camera, display, or color-science validation. Its job is to let a finishing team answer: what transformed this image, in which direction, for what display, and who approved the look?
Sources & evidence
Primary documentation establishes tool behavior or a reported production. Checklists and illustrative examples are Atlas editorial guidance, not results of independent testing. Match documentation to your installed version.
OCIO display, view, display-colorspace, and look-transform responsibilities.
Source published: Not established · Retrieved 19 September 2026
Input-transform role from camera/device values to ACES.
Source published: Not established · Retrieved 19 September 2026
Output-transform role from scene-referred ACES to a display-specific image.
Source published: Not established · Retrieved 19 September 2026
ASC CDL implementation and slope, offset, power, saturation controls.
Source published: Not established · Retrieved 19 September 2026