◎ Radiance OCIO Display/View

In a color-managed pipeline there are two kinds of transform, and confusing them is how you get footage that looks great in the graph and wrong on every monitor. A color space transform (the sibling ◎ Radiance OCIO Color Transform) moves data between working spaces. A display/view transform is the final one - it takes your scene-linear working image and renders it for a specific monitor, with a specific look. Radiance OCIO Display/View is that final node, and it's the one your image should pass through last.

It's built for the ACES way of working: you keep your data in a working space (ACEScg, linear) and decide at the end how it gets displayed - sRGB for a desktop monitor, Rec.709 for a broadcast reference, P3 for cinema. The view transform (like "ACES 1.0 - SDR Video") is what actually tone maps your linear values down to display range, and that's a real, opinionated piece of math, not a brightness slider.

How it works

Pick a display (the device: sRGB, Rec.709, P3-DCI, and so on) and a view (the transform: "ACES 1.0 - SDR Video", "Raw", "Log", "Un-tone-mapped"), and the node runs the matching OCIO processor. The defaults - sRGB display, "ACES 1.0 - SDR Video" view - are the exact combo 95% of people want for looking at ACES data on a normal monitor. Like the pack's other OCIO nodes, it caches the processor, so it's fast on repeat runs.

Two extras make it production-grade:

• look - an optional creative transform layered in (film emulation, a creative LUT). Leave it empty for a straight display; the industry's "looks" slot is here, exposed directly.
• exposure_adjust - an exposure shift in stops applied before the view transform, which is the correct place to adjust exposure (after would re-tone-map and clip).
• context_key / context_value - OCIO context variables (like shot or sequence). These let a single config branch on context, the way studios do for shot-specific grades.

The inputs that matter

• config_path - leave empty to use the OCIO environment variable or auto-detect ACES. Set it explicitly if you run a custom studio config.
• display / view - the two that decide the look. Use the pack's OCIO list node to see valid options for your config.
• look, exposure_adjust, context_key/context_value - the pro options. Most people ignore context entirely; just know it's there.

Output: the display-rendered image.

Why you'd reach for it

The full managed path looks like this: decode log footage (◎ Radiance Log Curve Decode) → work in linear ACEScg (◎ Radiance OCIO Color Transform) → grade in float (◎ Radiance Grade) → display here for review → deliver as EXR for the comp. The Display/View node is where "what I'm looking at" gets separated from "the data I'm actually delivering" - which is the entire point of color management. If you've been squinting at washed-out or oversaturated results from an ACES workflow and never understood why, this is the missing final step.

Installing

cd ComfyUI/custom_nodes
git clone https://github.com/fxtdstudios/radiance.git
cd radiance
pip install -r requirements.txt   # or requirements_windows.txt / requirements_linux.txt / requirements_mac_silicon.txt

Or search Radiance in ComfyUI Manager. Linux needs libopenexr-dev first; restart after.

Gotchas

The ordering trap is the big one: display transforms assume scene-linear input. If you feed it sRGB-encoded data, you get a double-curved, contrasty mess, because you're tone-mapping data that was already display-encoded. Check your chain. Second, Raw or Un-tone-mapped views exist to inspect linear data without a grade - selecting one and getting a dark flat image isn't broken, that's what linear looks like unrendered. Third, the defaults assume ACES; if you're running a non-ACES config, the sRGB/"ACES 1.0 - SDR Video" defaults may not exist in it, and the dropdown will tell you.