Banding induced by standard LTX 2.5 VAE Decode

#89
by Lordenpropf - opened

Trying to set up a 10 bit workflow I discovered banding in highly saturated areas of my videos.
So I set up a simple test after reading that setting the VAE encode and decode to float32 could help.

[1]. Just load a video with a VHS-Loader and directly save it
[2]. Load a video, convert it to latent with the standard encoder, decode it with the standard decoder and save it . (both the standard [2.1] bf16 and the [2.2] conv version)
[3]. replace the VAE Encode and Decode with the ANDRO nodes set to float32

[1| looks just fine
[2.1] serious banding
[2.2]much less banding, but in my actual production workflow, the convolutional version introduces a lot of noise
[3] no difference to the stock nodes

Can anyone point me to a solution for using the newer standard 2.5 VAE without introducing as much banding? Or a starting point for further reading?

Workflow in Comfy
Stock LTX 2.5 VAEs https://huggingface.co/Lightricks/LTX-2.5/tree/main/vae

Screenshot 2026-10-15 at 21.22.26

LTX.io org

Technically the force float32 node is there to solve just this, just connect it to the vae before encode/decode nodes

image

Unless you already start comfyui with the flag that ensures vae runs at fp32 the above node (or equivalent) is necessary, don't download the already bf16 var, just use the one in the checkpoint.

Thanks for your answer.
I already tried the force float node. I didn´t comment on that because the ANDRO node I mentioned under [3] does the same.
The force float node does not change anything, the output stays the same.
I have to add that for this test I work on log/flat footage and add contrast in post. And it is a very saturated color on a wall.
Nevertheless the banding also shows up if I work with the same footage already with a LUT applied from the start.

Screenshot 2026-10-19 at 09.12.27

comparison

@Lordenpropf as I mentioned above, you must pull the full precision fp32 vae from the checkpoint, you're using a bf16 (already downsized precision file), no amount of "forcing" will give it more precision, it's "baked" in bf16 already so you will always have the banding if you use that bf16 safetensors file.

I didn't find a fp32 checkpoint for the LTX 2.5 video vae. Am I missing something?
I read that upcasting in comfy to fp32 (--fp32-vae) could help, but it didn't change anything.

Edit: The one checkpoint I found states bf16 for the VAE Decoder part
https://huggingface.co/Lightricks/LTX-2.5-Pre-Trained

@Lordenpropf as I mentioned above, you must pull the full precision fp32 vae from the checkpoint, you're using a bf16 (already downsized precision file), no amount of "forcing" will give it more precision, it's "baked" in bf16 already so you will always have the banding if you use that bf16 safetensors file.

So they should download one of the two 42GB checkpoints and use the VAE from that? Wouldn't it be better if LTX provided a separate fp32 video VAE?

@oumoumad Same here — I couldn't find an fp32 video VAE anywhere either. I checked the safetensors headers directly:

  • LTX-2.5/vae/ltx-2.5-video-vae-bf16.safetensors → all 396 tensors BF16
  • LTX-2.5/vae/ltx-2.5-video-vae-conv-bf16.safetensors → all BF16
  • LTX-2.5-Pre-Trained/ltx-2.5-22b-pt-bf16.safetensors → vae.* tensors (396) are all BF16, identical to the standalone file
  • The 42GB dev/distilled transformer files in diffusion_models/ don't contain a VAE at all

So as far as I can tell, there's no checkpoint with an fp32 VAE to pull from. Could you point us to it, or release a separate fp32 video VAE? Thanks!

I stand corrected, you don't need a float32 precision weights to conserve your pixels at fp32 precision,
@Lordenpropf are you sure you don't have any other node in between? even a resize node? can you share your workflow ?

My workflow is in the earlier post.
There is a resize node but I exported
1: with the resize node present but without VAE encode and decode - no banding
2: with VAE encode and decode - banding

image

Sign up or log in to comment