Color

Color Nodes

Use color nodes in Oraphim with a production-safe workflow, practical example, verification steps, and common failure checks.

Updated August 28, 2026

Color nodes

Nodes organize a grade into explicit processing steps.

Visual reference

Color node graph

Use one node for one clear job when possible; readable node structure makes grades easier to troubleshoot and revise.

Node types

Serial nodes process one after another. Parallel branches and layer mixers combine corrections. Key mixers combine matte inputs. Outside nodes invert a source key for complementary work.

Shared nodes can link a correction across clips. Group pre-clip and post-clip structures support common scene-level adjustments around clip-local grades.

Node controls

Nodes can be selected, labeled, colored, disabled, bypassed, framed, and versioned. Connections determine evaluation order.

Safe graph editing

Avoid cycles. If a correction is not producing the expected result, inspect node enable state, key inputs, mixer order, and the active viewer mode.

Persistence

Node data is stored with the grade and restored with the project. Shared and group relationships remain part of the project color state.

Use Color Nodes in a production project

  1. Open Color workspace and select the intended explicitly selected clip or color source.
  2. Establish the correct input state first—timing, media link, layer/node enable state, project settings, or source selection as relevant.
  3. Apply or adjust Color Nodes with one clear goal. Change the smallest set of controls needed to reach that goal so the result remains understandable and reversible.
  4. Review the complete affected range in context. Scrub difficult frames and also play at normal speed when motion or audio is involved.
  5. Save a named milestone before moving into another major operation, especially after graph changes, tracking, AI processing, relinking, simulation, or delivery setup.

Practical guidance

Use color nodes only where it solves a defined creative or technical problem, and compare the result against the untreated state.

A useful test is a short 5–10 second section containing both an easy case and a difficult case for this feature. Tune against the difficult moment without breaking the easy one. If two approaches are plausible, duplicate/version the project state and compare them rather than stacking both together blindly.

Verify the result

  • Check scopes, normal viewer output, and a rendered review rather than trusting one still frame.
  • Toggle/bypass the operation where possible and make sure the change you intended is actually responsible for the result.
  • Check selection, visibility/mute/solo state, node connections, track locks, range, and source identity when the result appears missing.
  • Save and reopen before treating a complex setup as reusable.
  • If this feature changes final pixels or audio, render a short review and inspect the file outside Oraphim.