🅛🅣🅧 LTXVVAE Force Float32

This is the least glamorous node in ComfyUI-LTXVideo's HDR set and the one most likely to bite you. It has no parameters, one input and one output, and its entire job is to make the LTX video VAE run in float32 instead of float16. That's a requirement for native HDR, not an optimisation - and the way it achieves it is the interesting part.

Why HDR needs float32 at all

The VAE's whole career is compressing pixel values into latents and back. In float16 it has about three decimal digits of precision and a limited exponent range, which is perfectly fine when your images live in [0, 1]. HDR does not live in [0, 1]. Once LTXVHDRDecodePostprocess decompresses the VAE output back to scene-linear values - ACEScg linear, unbounded, highlights in the tens - a float16 round trip quantises exactly the highlight detail you went to all this trouble to keep. The HDR IC-LoRA and the native EXR path both assume the encode/decode happens at float32; you can't skip it and hope.

The cost is real: float32 weights are double the memory and the decode is slower. That's why it's a separate node you opt into rather than a default in the VAE loader.

What it actually does - and the trap

The method is two lines: it sets vae.vae_dtype = torch.float32, then casts the VAE's first_stage_model weights with .to(dtype=torch.float32).

Note what it does not do: clone the VAE. It mutates the object you passed in and returns that same instance. The author is blunt about this in the node's own description, and it's the thing to internalise:

If you also wire that loader's VAE (or this output) into another branch, those nodes share the mutated model: they may see float16 or float32 depending on execution order - a race with the original dtype.

So picture the graph where you feed one VAELoader into this node and directly into a normal SDR decode somewhere else. Both branches now point at the same underlying model. Whichever runs first decides what the other one sees. Sometimes the SDR branch gets float32 (slower, more memory), sometimes the HDR branch gets float16 (broken highlights). It's order-dependent, which means it can work fine on your machine and fail after you add an unrelated node. That's the worst kind of bug.

The fix is a wiring rule, not a setting: one chain. VAELoader → LTXVVAEForceFloat32 → every encode, decode and IC-LoRA guide in the graph. If you genuinely need a float16 path as well, load a second VAE with a separate loader and keep it out of this node's reach. Two VAE objects, two dtypes, no race.

Inputs and outputs

There's nothing to tune.

• Input: vae (VAE).
• Output: VAE - wire it into VAEEncode, VAEDecode, and the IC-LoRA guide nodes.

If the cast fails it raises LTXVVAEForceFloat32 could not cast VAE weights to float32, with the underlying exception attached. In practice that's a memory error or a VAE object that isn't what the node expects - but at least it fails loudly rather than silently handing you a float16 decode.

Install

It's a plain Python node in the pack, so the install is the pack's. ComfyUI Manager → Ctrl+M → Install Custom Nodes → search LTXVideo → Install → restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/Lightricks/ComfyUI-LTXVideo

No extra dependencies for this one - just torch and a loader's output. The pack as a whole does need colour-science and openimageio (that's what the HDR nodes import), so if the HDR category is missing from your node menu, that's a broken requirements install, not a problem with this node. The honest hardware note from the README: LTX-2.3-era HDR work is quoted at 32GB+ VRAM and 100GB+ disk, and forcing the VAE to float32 pushes that up. If you're near the ceiling, that's where the pack's low-VRAM loader nodes and --reserve-vram earn their keep:

python main.py --reserve-vram 5

Where it belongs in the graph

In the native HDR path, the order that works is: LTXVLoadEXRSequence for the plates → LTXVVAEForceFloat32 on the VAE → encode/sample → decode → LTXVHDRDecodePostprocess (transfer=acescct) → LTXVSaveHLG from its hdr_linear output. In the SDR→HDR IC-LoRA path it's the same story after the guide, with LTXVSDRToHDRWorkingSpace sitting in front of the resize.

The pack ships these as working graphs in example_workflows/2.5/ - LTX-2.5_I2V_Native_HDR_Two_Stage_Distilled.json and LTX-2.5_ICLoRA_HDR_Distilled.json. Load one, and notice that the float32 VAE node sits inline on the VAE wire with nothing else sharing it. That's not a stylistic choice. That's the fix.