ACES 2.0 Output Transform (Legacy)

The short version

This is the previous generation of Radiance's ACES 2.0 output transform. It's marked DEPRECATED = True in the source, which in practice means it's hidden from the node menu - you can't right-click and find it - but any workflow you saved that uses it still loads and still renders correctly. That's the whole design intent: the newer, reference-accurate node took its name, and the old one was kept as a quiet compatibility path instead of being deleted and breaking people's graphs.

So if you searched for it, you probably have one of two situations: an older workflow that contains it, or a tutorial that predates the rename. In the first case, leave it alone unless you're re-rendering for delivery. In the second, you want RadianceACES2OutputTransformFull instead.

What changed and why it matters

The Full node's docstring is blunt about it: it "supersedes the legacy ACES2OutputTransform for high-accuracy deliveries requiring full Academy S-2126 compliance." The legacy implementation still has a fix list attached to it from its own v2.1 pass - it used to hard-clip the tonescale to [0,1] even on HDR outputs, which flattened everything above 100 nits into white, and its PQ encoder was being handed the wrong range. Those are fixed here. But the newer node runs the ACES 2.0 reference tonescale and the official reach gamut compression, and this one predates that rewrite.

That's the honest framing: not broken, just older maths.

The inputs and outputs

The surface looks identical to the Full node and isn't quite. image, input_colorspace (ACEScg / ACES2065-1 / Linear_sRGB / Linear_Rec2020) and output_transform (the same eight SDR, HDR and Cinema targets) are the required inputs.

Then the differences, which are the kind that bite during a swap:

• gamut_compress here, not gamut_compress_strength in the new node. Range 0–2, default 1, where 1.0 is standard and higher squeezes harder.
• creative_white_scale is capped at 1.5 rather than 2.0. It's still a creative exposure trim applied before tone mapping.
• exposure_adjust in stops, peak_luminance in nits (SDR standard is 100), and surround with the same Dark / Dim / Average choices - cinema, home theatre, office respectively.

The output socket is named output_image, and that's worth knowing: the Full node returns image. Repoint the wire by hand when you swap nodes, because a workflow that silently loses a link is much harder to debug than one that refuses to validate. transform_info comes out alongside it as a string recording what ran.

Which one to reach for

New work: the Full node. Old graphs: this one, unchanged, unless you're re-delivering - and if you are re-delivering, re-grade rather than assuming the swap is a no-op, because the tonescale and gamut stage are genuinely different algorithms, not a bug fix with the same output.

If you only want part of the chain, note that Radiance exposes the pieces separately: ACES 2.0 Tonescale for the curve alone and ACES 2.0 Gamut Compress for the gamut stage alone. If you want to preview fast without the full transform, ACES Transform is the cheap fitted approximation. Those three plus the Full node cover essentially every reason to keep the legacy node around - which is exactly why it's hidden.

Install

Same pack, same steps. ComfyUI Manager → search Radiance → install → restart → refresh. Or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/fxtd-studios/radiance.git
cd radiance
python -m pip install -r requirements.txt

Windows portable users need ComfyUI's bundled python_embeded\python.exe for the pip step. The pack's install.py checks for OpenEXR, PyOpenColorIO, diffusers and accelerate, and OCIO is configured at startup from $OCIO or OpenColorIO's built-in ACES studio config.

Gotchas

• It's in the menu but hidden. If you can't find it in the node search, that's not a broken install - the class sets DEPRECATED, so the menu skips it. Load a workflow that uses it and it appears.
• The socket names differ from the new node. output_image vs image.
• The ranges differ. Copying widget values between the two nodes by hand can push a setting out of range.
• Same input rule as the new node: the image must be scene-linear. A display-encoded sRGB input produces a crushed, dark result either way.
• Migrating from a pre-3.5 install? The changelog flags that some nodes and widget layouts changed in v3.5 - back up your workflows before updating, because the pack's own docs say so.