VAE Encode

If you've ever used the stock VAE Encode, you know the deal: pixels in, latents out. Nifty's version is that, plus one feature that matters specifically if you work with video: it can encode only a subset of your frames so the result matches a target latent count. For still images it's a drop-in replacement. For video pipelines it's the difference between a clean latent and a workflow full of arithmetic nodes trying to make frame counts line up.

The reason this exists: video VAEs compress temporally. Wan's 3D causal VAE, for instance, folds a run of frames into a single latent - so "how many latent frames do I get from N pixels frames" is not N; it's something like (N-1)/temporal_factor + 1. When you're doing image-to-video and you need the encoded start frames to land on a specific latent count, the stock node makes you slice frames yourself and pray. This node detects the compression factor automatically and does the slicing for you.

How it works

The magic is in target_latents. Set it to 0 (the default) and it encodes every frame, exactly like stock VAE Encode. Set it positive, and it encodes only enough frames from the start of the batch to produce the first N latents. Set it negative, and it takes frames from the end to produce the last N latents.

To figure out how many frames that is, the node probes your VAE: it encodes a small test slice (up to 9 frames) and infers the temporal compression factor from the shape of the output - a 5D output means it's a video VAE and the factor comes out of the frame ratio, a 4D output means no temporal compression and the factor is 1. If the probe fails for any reason it falls back to a factor of 4. That's the whole "detected automatically" promise in the tooltip, and it's a genuinely nice piece of engineering.

Inputs and outputs

• pixels - the image frames to encode (IMAGE).
• vae - the VAE to use (VAE).
• target_latents - 0 = encode all frames; positive = only the first N latents' worth; negative = only the last N. Range −4096 to 4096.
• LATENT - the encoded latent samples, ready for a sampler or latent node.
• IMAGE - your original pixels, passed through unchanged. This is a passthrough output, so you can use the same node to feed both a latent pipeline and an image pipeline without adding a reroute.

When you'll actually use it

Most of the time you'll leave target_latents at 0 and it behaves identically to the stock node - same inputs, same output, no downside. It earns its keep in video workflows where frame count alignment matters, which on Wan 2.1/2.2 is everywhere: the models have specific latent requirements and the community is full of "why is my video N frames off" threads. If you're building an I2V workflow and you want the conditioning image to encode to exactly K latents, set target_latents to K and stop worrying about how many pixels frames that implies.

Installing it

Part of Nifty Nodes for ComfyUI (Stibo/comfyui-nifty-nodes). ComfyUI Manager → search "Nifty Nodes", or:

cd ComfyUI/custom_nodes
git clone https://github.com/Stibo/comfyui-nifty-nodes

Restart after. The pack needs the v3 API (comfy_api.latest), so keep ComfyUI current. No extra pip packages, no model files - it uses whatever VAE you already have.

One small heads-up

The inplace-style efficiency tricks you see elsewhere aren't here, so for very long video batches this encodes what it needs and that's that. And remember the temporal factor probe does a tiny extra encode on the first run - it's a few frames, not a full pass, so don't be startled by a brief hiccup before the real encode starts.