Video Batch Decode

ComfyUI has a VAE Decode node. For video latents it's not enough - you want memory management, a tiled path when VRAM runs out, and, the reason most people open this node at all, a switch to hand the frames out as scene-linear instead of display-referred sRGB.

What it does

Inputs are vae and latent. Give it a 5-D latent and it goes through the VAE's temporal path rather than trying to decode a video latent as a stack of stills. dit_config (optional) takes the JSON string from Video Model Info - and the tooltip is precise about how it's used: its compression values are consulted "only if the VAE does not report its own," and its latent_scale is not applied, because a ComfyUI sampler already returns the latent in VAE space. That's the kind of detail that saves you an hour of wondering why a scale factor had no effect.

Then the interesting widget. output_linear (default off) converts the VAE's display-referred sRGB frames to scene-linear via an inverse sRGB transfer. Off, you get what VAE Decode gives you: sRGB clamped to 0–1. On, you get float linear - which is what every HDR node in this pack wants to see. Wire output_linear on into SDR → HDR Universal, or into the colour nodes, and the transfer curve is already handled.

Memory handling: tile_decode (off by default) routes the decode through ComfyUI's own tiled entry point (comfy.sd.VAE.decode_tiled) to cut peak VRAM. The tooltip's advice is worth repeating because it contradicts the instinct to turn it on: leave it off, because "an untiled decode already falls back to tiling by itself when it runs out of memory." Turn it on deliberately if you want to control peak memory rather than discover it, and then tile_overlap (default 64) matters - higher means smoother seams. It's only read when tile_decode is on, so changing it otherwise does nothing at all.

Outputs: frames (IMAGE), frame_count (INT - cheap and genuinely useful for sanity-checking the frame arithmetic your sampler produced) and decode_report (STRING).

Why not just VAE Decode

Three reasons, in order of how much they matter. The linear output, because converting the pixels to scene-linear is the handoff that every HDR and ACES node in this pack expects, and doing it with a correct inverse sRGB transform beats wiring your own curve node and hoping. The tiled path, because video latents are the size where VRAM actually runs out. And the report/count outputs, which turn "why is my clip 24 frames and not 25" from a mystery into a number.

Also worth knowing: the pack's own known-issues list warns that HDR through a VAE is lossy in the highlights - VAE Encode (HDR) and VAE Decode (HDR) invert each other exactly, but the diffusion pass between them doesn't, and the log-coded latent's small errors grow as the curve steepens. Measured on an SD 1.5 VAE with a plate peaking at 8.4: median error 0.09 stops, 96% of values above 1.0 stayed above 1.0, and the brightest speculars can overshoot. Midtones hold. So if you're decoding a latent for HDR work, do the HDR encode after this node - decode to linear, then uplift - rather than trying to carry HDR through the latent.

Install

1. ComfyUI Manager → search Radiance → Install → restart → refresh the browser.
2. 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: python_embeded\python.exe for the pip line. The pack's install is chunky (OpenEXR, OpenImageIO, OpenColorIO, diffusers) and its install.py verifies the colour libraries after a Manager install. You still supply your own VAE; this node downloads nothing.

Gotchas

Decoding is the moment VRAM peaks in most video workflows - if a graph OOMs on the last node, it's usually this one, and the answer is tile_decode on with a smaller tile rather than a smaller window upstream.

And don't use this to convert an already-decoded clip to linear. It's a decoder: it wants a latent. For an IMAGE batch, the pack's RadianceFloat32Convert and colour-space nodes are the right tools.