Write EXR Passes

Radiance can estimate a set of render passes from a single image - beauty, depth, normals, material and lighting passes, that whole approximate AOV stack. Write EXR Passes is how you get that bundle out of the graph and onto disk as a real OpenEXR file a compositor can open.

What it is

One input, passes, of type RADIANCE_PASSES. That's a bundle, not an image - it's the thing Radiance's Multipass Estimate, Multipass Master and AOV Reader nodes produce and consume. Plug it in and the node writes the whole set to <filename_prefix>.<frame, 4-digit>.exr, incrementing the frame number from frame_index (default 1001, VFX standard).

It has to contain a beauty pass, and every pass must be the same width and height. Pixel values are written as-is with no colour conversion, same contract as the single-part writer: what you feed it is what lands on disk.

The one setting that has opinions

exr_layout decides the file structure:

• Single-part multilayer (default) - all passes as named channel layers inside one EXR part. Widest compatibility; this is what most comp software reads without ceremony.
• Multi-part - a true EXR 2.0 part per pass.

Single-part is the right default and I'd leave it there unless a specific tool demands otherwise. Multi-part is technically tidier and more modern, and roughly half the tools you'll hand it to will read one part and act confused about the rest.

compression is where this node is smarter than most: ten options, and lossy B44/B44A/DWAA/DWAB raise an error when data passes are present. The node knows that depth, world_position, motion_vector and object_id are not pictures - compressing them lossily is how you get a depth map with visibly wrong values and a defocus that "looks off" for reasons nobody can name. There's a companion rule: a file containing any of those data passes is always written as 32-bit float, even if you asked for half. Both of those are exactly the kind of guard rail you want in a node written by people who've cleaned up after a bad handoff.

Optional bits, all the same shape as the other Radiance writers: output_path (empty = ComfyUI's output folder, relative nested inside it, absolute used as-is), remote_path for an automatic copy to a NAS or share (a failed copy only warns), and custom_metadata for extra header attributes, one key=value per line, storage as strings, blank lines ignored.

Output is output_path, and it's an output node.

Install

Radiance, the usual way. Manager → search Radiance → install, restart ComfyUI, refresh the browser. Manual:

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: use python_embeded\python.exe for that pip line, or the dependencies land in a Python that ComfyUI never imports. No separate model download for this node, but the nodes that produce a pass bundle do have models - Multipass Estimate pulls substantially larger downloads than the SDR→HDR model.

Where people get burned

The pass bundle is expensive to hold. Radiance's own release notes say Multipass Estimate's geometry passes keep the whole clip on the CPU, and the composite-side nodes return multiple full-size images, so a long 4K clip can need double-digit clip-sized buffers in RAM. Split long clips. If you're writing 200 frames of six passes from a 4K sequence, you don't have a disk problem, you have a memory problem first.

Second: those passes are estimates, and the pack says so plainly. Depth and material predictions vary frame to frame and video can flicker. Writing them to EXR doesn't make them measurements - the file is authoritative about what it contains, not about whether the lighting is correct.

Third, the ordinary one: filename_prefix is a stem, not a path. Put your directory in output_path and leave the prefix as a name, or you'll get a creatively-named folder somewhere you weren't looking.