◎ Radiance Nuke Bridge

This is the node that tells you exactly who Radiance is for. Most ComfyUI users export a PNG and call it done. Compositors need their AI frame to show up inside Nuke, in the Viewer, at the correct color space and bit depth, without exporting, importing, and explaining. Radiance Nuke Bridge does that: it writes your image to a float32 EXR, then tells a running Nuke to create a Read node connected to the Viewer. The whole pipeline is IMAGE → EXR file → TCP command → Nuke Read → Nuke Viewer.

It's a production bridge, not a toy, and it comes with a real expectation: you need Nuke open, with the pack's scripts/start_nuke_server.py running inside it, listening on a TCP port. The node is the client half; the script is the server half.

How it works

The node writes the image using the pack's Radiance IO backend - the same one behind its EXR save - with real control over the file:

• bit_depth - 32-bit Float (max quality) or 16-bit Half (smaller files). Default float, which is the point of the pack.
• compression - ZIP (fast, good ratio, the default), ZIPS, PIZ (best for noisy image data), DWAA, or None.
• depth_map - an optional second image written as the EXR's Z channel, which then shows up in Nuke as depth. Nice little compositing gift.
• start_frame - defaults to 1001, the VFX convention for first-frame numbering.
• output_path - where the EXR lands. Empty = ComfyUI's temp dir; for a remote Nuke machine you'll want a shared drive path.

Then it sends a TCP command to host:port (default 127.0.0.1:1986 - same machine) telling Nuke to create or update a Read node named stream_name and connect it to the Viewer if connect_viewer is on. Because the Read node is reused by name across updates, you don't accumulate duplicates - every run refreshes the same node.

send_mode is the traffic control: Always sends every execution; On Change skips when the image is unchanged (perceptual hash); Never writes the EXR but skips the Nuke command entirely - useful for batching files without spamming the viewer. color_space (linear, sRGB, raw, AlexaV3LogC, ARRI LogC4, S-Log3, V-Log, Canon Log 3, ACEScg, ACEScct) sets the Read's colorspace knob to match your pipeline, and raw bypasses Nuke's color management so data passes through exactly as written.

Outputs: image (pass-through) and nuke_status - a string telling you what Nuke did, or didn't.

Setup

Server side, inside Nuke's script editor or a Nuke startup script, run the pack's scripts/start_nuke_server.py. That's the piece people miss - without it the node writes EXRs happily and then has nobody to command, so frames don't appear in Nuke.

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 (EXR is core to this node); restart after.

Gotchas

The failure modes are all "the bridge isn't there." No Nuke server → nuke_status reports it can't connect and frames pile up as orphan EXRs (watch output_path). Wrong stream_name → Nuke creates a new Read each run instead of updating, which is the duplicate-node symptom. And the standing pack rule applies here hardest of all: the EXR is only as float as your data. The community's one critique of this pack was that it "won't create real 16/32 bit EXR" unless the input actually carries the data - this node writes true float32 files, but if your upstream is 8-bit sRGB, the file is honest float holding 8-bit information. Garbage in, technically-float garbage out.