ANDRO VAE Decode

Every stock VAE decode in ComfyUI finishes with this line:

process_output = lambda image: image.add_(1.0).div_(2.0).clamp_(0.0, 1.0)

That's a [-1,1] → [0,1] rescale followed by a hard clamp. Decoders routinely emit values past [0,1] - the pack's own measurements across a bunch of VAEs found ranges like -0.0196 … +1.0186 and -0.0715 … +1.0445, with 0.01–0.34% of samples outside the bounds. That's the top of your speculars and the toe of your shadows getting deleted before any node downstream can see them. On top of that, most VAEs decode in bfloat16, which quantises the output to roughly 77 distinct levels in a mid-band instead of the 3.3 million float32 can hold. Neither loss is visible in the graph - the image still looks fine, it just can't survive a grade.

VAE Decode (float32, no clamp) is a drop-in replacement for VAEDecode / VAEDecodeTiled that gives both back. If you push AI frames into DaVinci, an EXR pipeline, or any sort of color-managed VFX handoff, this is the node the pack exists for. If you're exporting 8-bit PNGs to share, honestly, skip it - an 8-bit container physically can't hold what this saves, and you're adding decode time for nothing.

How it works

At decode time the node temporarily swaps vae.process_output for the same maths minus the clamp, optionally casts the decoder weights and vae_dtype to float32, and restores everything in a finally block - so other graphs in the same session are unaffected. Two guardrails matter:

• It does not assume every VAE uses the [-1,1] → [0,1] default. TAEHV/lighttae, MiniMax H3 and StageA already emit [0,1] and set an identity transform; substituting the default there would rescale the image and wreck it. The node probes the VAE's own transform with -1/0/1 and leaves anything unfamiliar alone, reporting it.
• The float32 cast is guarded - quantised weights refuse the cast gracefully and the node falls back to the VAE's own precision with a note.

It reaches into vae.process_output, vae.vae_dtype and first_stage_model, none of which are public API, so a ComfyUI refactor could break it. That's why the fallbacks exist: a surprise degrades into "no change, with a note" rather than a corrupted image.

The inputs that matter

• keep_out_of_range (default on) - off reproduces stock ComfyUI exactly. On keeps the undershoot/overshoot so an EXR can carry it. This is the "am I sure I'm not just seeing a different decode" switch for A/B testing.
• precision (float32 default, or vae default) - the cost is real: roughly 3× decode time and 2× the VAE's VRAM.
• tiled plus tile_size - and here's the trap. The node defaults to tile_size 384 for a reason. In bf16, 384 and 768 cost the same; in float32, 768 becomes a cliff: the pack measured a 12-second decode turn into 21 minutes, no error, just a progress bar that stops moving. ComfyUI's own LTX-2.5 template ships VAEDecodeTiled at 768, which is fine for bf16 - swap in float32 and leave it, and you've made yourself a twenty-minute decode. Halve the tile. temporal_size (default 4096) you should generally leave high: a temporal tile edge has no context, and the blend leaves a soft frame on every seam. Tile Seam Check from this same pack will tell you when one sneaks through.

Outputs

image wires straight into anything a stock decode feeds - SaveImage, Save EXR (float32), upscalers. range_report is a STRING with the decoded min/max and a note if anything was skipped or unrecognised; stick it in a text display or just read the console.

Install

ComfyUI Manager (search "comfyui-vae-float32"), or:

cd ComfyUI/custom_nodes
git clone https://github.com/AndreiOrehov/comfyui-vae-float32

Restart ComfyUI. No model downloads - it works with whatever VAE you already have. pip install OpenEXR only matters if you want EXR output (the pack falls back to float TIFF otherwise).

Where people get burned

• The tiling cliff above. If a float32 tiled decode crawls, your tile_size is too big, not too small.
• LTX heights. The latent grid floor-divides by 32, so 1080 silently becomes 1056. Use 1088 or 1056 and know which one you picked.
• MiniMax H3, once. The README records a one-off ValueError: Buffer too small that never reproduced; if you ever hit it, precision: vae default sidesteps the cast.
• "Nothing changed" is a feature. The two decodes look identical - that's the point. Measure the difference with Image Compare (numeric) from this pack; that's what it's for.