Export to Nuke

Export to Nuke does the small annoying half of a handoff that normally eats twenty minutes. It writes your frame as EXR into the shot folder and writes a .nk file containing a ready-made Read node pointing at it. Drag that snippet into your comp script and you're working. No typing paths, and no re-typing them after the next iteration.

That sounds like a small thing. It isn't, if you do this for a living. It's Radiance trying to make ComfyUI a citizen of a real VFX pipeline instead of a black box beside one, and the KB's post-processing.md §(b) is honest that this corner is nearly invisible in the community at large - which is exactly why a node like this exists rather than a bunch of forum posts.

What it writes

image is required. A single frame writes one EXR; a batch writes a numbered sequence starting at frame_start (default 1001, because that's the VFX convention and yes, the default is right). nuke_folder is the output folder and gets created if missing. filename is the base name for the files, and the same string becomes the Read node's name with anything Nuke won't accept in a node name replaced by an underscore.

half_float defaults on, which writes 16-bit half EXR. Untick it for 32-bit float. Half is the sane default - half the file size, and 16-bit float has plenty of range for most handoffs. Go 32-bit when you're passing something through where the mantissa matters.

input_space is the field worth thinking about, and its default is deliberately conservative. EXR is written scene-linear, so sRGB display linearises first, Scene-linear means take me at my word, and As is (no conversion) writes values unchanged. This is the one setting that quietly ruins comps: feed the node a plain LoadImage PNG, leave it on As is, and you've written gamma-encoded values into an EXR that Nuke will treat as light. Everything blows out and looks like a colour-management disaster.

Two outputs, both strings: status and render_path. Wire render_path into a note or an overlay is the easy way to keep track of what you just delivered.

Pushing into a running Nuke

push_to_nuke is off by default and it's the showy option: instead of writing a snippet you import by hand, the node talks to a Radiance listener running inside Nuke and creates or updates the Read node there. The requirements are specific, so read them twice.

• Run scripts/start_nuke_server.py inside Nuke. It ships with the pack.
• Both sides authenticate with a token from ~/.radiance/dcc_token, created automatically, or from RADIANCE_DCC_AUTH_TOKEN. If Nuke is on a different machine, copy that file over or set the variable there.
• nuke_host (default 127.0.0.1) and nuke_port (default 1986) point at the listener, and both have environment overrides: RADIANCE_NUKE_HOST and RADIANCE_NUKE_PORT.

Only the push path uses host and port. Leave it off and they're inert.

Install

ComfyUI Manager → search Radiance → install → restart → refresh. Or:

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

EXR writing is the dependency that matters here. Radiance uses the OpenEXR wheel when one exists and falls back to OpenImageIO otherwise - relevant because there's no OpenEXR wheel for Python 3.14 yet, and the pack deliberately degrades to OpenImageIO then OpenCV rather than failing the install. If EXR output is behaving oddly, check the console first and confirm which path loaded.

Where people get burned

• Frame numbers. The default frame_start is 1001. A batch of 40 writes 1001–1040 and the Read node says so. If editorial expects frames starting at 1, change it before you deliver.
• Name collisions. Export twice with the same filename into one comp and you'll get a radiance_out1. Name per shot.
• No listener. push_to_nuke on with nothing listening fails - and still leaves a perfectly good EXR and .nk on disk. The write always happens; the push is a bonus.