CDL
The grade that survives being handed to someone else
- image
- image
- cdl_info
What a CDL is, and why you'd use one
ASC CDL is a fixed, boring, thirty-year-old grade format: slope (gain), offset, power (gamma), and a saturation - per channel, plus one global saturation. It's the interchange format of the grading world, which is the entire argument for it. A CDL means the same thing in Resolve, Nuke, Baselight, a LUT box on set, and this node. Ten numbers, fully specified, no ambiguity.
That matters in a ComfyUI context more than you'd think. If you've tuned an image with a pile of slider nodes and then want to hand that grade to someone in Resolve, you either spend twenty minutes translating it by eye, or you keep the grade in CDL form from the start and hand over a file. Radiance ships three CDL nodes so you can do the second thing: this one applies a grade, plus import and export for moving it around.
The maths
The order is fixed by the spec and the node follows it: each channel gets (value * slope + offset) ** power, then saturation is applied around luma. Slope scales, offset lifts or subtracts, power bends the highlights and midtones without moving black the way offset does. Saturation at 1.0 is unity, 0 is greyscale.
Worth knowing: no colour space conversion happens. The grade is applied to the values exactly as they arrive. So a CDL authored on LogC footage in Resolve must be applied to LogC values here, or you're grading different numbers than the colourist was. The tooltip says this outright - "feed it the encoding the CDL was authored in" - and it's the single most common way a CDL round-trip goes wrong.
Inputs
image, then ten required numeric widgets: slope_r/g/b (default 1, range 0–4), offset_r/g/b (default 0, range −1 to 1), power_r/g/b (default 1, range 0.01–4), and saturation (default 1, range 0–4).
Ten widgets is a lot of UI for one grade, and the practical way to use this node is to not touch them at all. Wire cdl_data - the optional STRING input - from CDL Import or from the cdl_info output of another CDL node, and its values replace the sliders entirely. That's the workflow: the grade lives in a file, the node is a pass-through with a data input, and the sliders are there for manual work and for when you don't have a file yet.
Note the offset range caps at ±1, which is a narrower window than some grading tools allow. If a reference CDL lands outside it, you're looking at a value that was authored to be applied elsewhere in the chain.
Outputs
image and cdl_info - a JSON string carrying the slope, offset, power and saturation values that were used. Chain it into another CDL node's cdl_data, feed it to CDL Export to write a file, or log it. Once you're using the JSON path, cdl_info is effectively your grade's identity; treat it as the thing you archive.
Where this fits
For a look you want to reuse across shots: build it once, export the CDL, import it on every subsequent clip. For a colourist relationship: you match a reference, export the file, send it, and their Resolve applies your intent exactly. For your own pipeline: it's the only grade in this pack that's a documented standard rather than a set of sliders, and that's worth something the first time you have to explain why two images don't match.
Where it's the wrong tool: anything creative. CDL cannot do a hue curve, a selective correction, or a vignette. It's four primitives in a trench coat.
Install
ComfyUI Manager → search Radiance → install → restart → refresh the browser. 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: use the bundled python_embeded\python.exe for the pip command. This node is pure torch. The pack's XML and file-side dependencies (defusedxml for the AMF/CDL parsing, OpenImageIO for DPX and EXR writes) are declared in requirements.txt, so a README-following install has them.
Gotchas
- Applying a CDL to the wrong encoding. The grade is meaningless out of its original space. If a CDL looks insane, you're feeding it the wrong values.
- Wiring
cdl_dataand then wondering why the sliders do nothing. They're overridden by design. - Expecting
powerto behave like a gamma slider on display-encoded footage. It's a power function on whatever numbers arrive; it's not "exposure". - Offset outside ±1. The node clamps the range. A CDL from a tool with a wider window will lose information.
- Reading
cdl_infoas optional. It isn't, if you want the grade to be reproducible.
Inputs (12)
| Name | Type | Default | Description |
|---|---|---|---|
| image | IMAGE | Image to grade. The CDL maths is applied to the values as they arrive (no colour space conversion), so feed it the encoding the CDL was authored in. | |
| slope_r | FLOAT | 1.000–4 | Red channel slope (gain). 1.0 = unity. |
| slope_g | FLOAT | 1.000–4 | Green channel slope (gain). 1.0 = unity. |
| slope_b | FLOAT | 1.000–4 | Blue channel slope (gain). 1.0 = unity. |
| offset_r | FLOAT | 0.000-1–1 | Red channel offset. 0.0 = no shift. |
| offset_g | FLOAT | 0.000-1–1 | Green channel offset. 0.0 = no shift. |
| offset_b | FLOAT | 0.000-1–1 | Blue channel offset. 0.0 = no shift. |
| power_r | FLOAT | 1.000.01–4 | Red channel power (gamma). |
| power_g | FLOAT | 1.000.01–4 | Green channel power (gamma). |
| power_b | FLOAT | 1.000.01–4 | Blue channel power (gamma). |
| saturation | FLOAT | 1.000–4 | Global saturation. 1.0 = unity. |
| cdl_dataopt | STRING | JSON CDL data from Radiance CDL Import. When connected, its slope, offset, power and saturation values replace the sliders above. |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| image | IMAGE | — |
| cdl_info | STRING | — |