TS LTX HDR VAE

Stock ComfyUI's Load VAE doesn't ask what precision you want - model management picks bf16, which is plenty for a picture and not enough for a master. The quantization step in the shadows and the top stops is exactly where HDR lives, so decoding a scene-linear master through a bf16 VAE eats the range you went to all that trouble to preserve. TS LTX HDR VAE loads the same VAE file at an explicit precision, defaulting to float32.

That's the whole node. It doesn't do anything exotic; it just refuses to let the precision be an accident.

How it works

The required input is vae_name - normally the same file the rest of your graph uses. The precision dropdown defaults to float32, and the tooltip is candid: float32 is the point of this node; the other options exist for measuring what the precision actually buys you. If you want to know whether bf16 really costs you the range on a given shot, load both and compare - that's a legitimate use, and it's why the other precisions are there.

Everything else in the graph keeps the VAE it already had. This node is wired only into the hdr_vae input of TS LTX HDR Decode, and nowhere else. That input is lazy, which is what keeps a second copy of a video VAE out of memory while HDR is off - if you're not doing HDR, the float32 VAE never loads, so keeping this node in the graph is free.

Inputs and outputs

• vae_name - the VAE file, normally the same one the rest of the graph uses.
• precision - default float32. The point of the node.
• config (optional) - the settings node, only used to say so in the log.

Output: vae - connect to the hdr_vae input of TS LTX HDR Decode, and nowhere else.

Installation

Part of the comfyui-timesaver pack. Install via ComfyUI Manager (search "Timesaver") or:

cd ComfyUI/custom_nodes
git clone https://github.com/AlexYez/comfyui-timesaver
cd comfyui-timesaver
python -m pip install -r requirements.txt

Restart ComfyUI. It's under TS/Video/HDR.

When to use it

When HDR is on. The rule is that simple. If you're running the preserve-from-EXR path, wire this into the decoder's hdr_vae socket and let the rest of the graph use whatever it was already using for everything else. If HDR is off, leave it unwired - the decoder falls back to your normal sdr_vae and the float32 copy never touches VRAM.

One honest caveat: a float32 decode of a long clip is heavier than a bf16 one. That's why the decoder has tiling controls - keep tiled on for long clips and the memory stays sane. The precision is where the quality lives; the tiling is how you afford it.