WanVideo Encode Latent Batch

Most of the time you feed Wan a single init image and let it animate forward. This node is for the other case: you've got a whole batch of images and you want each one turned into its own latent, so you can use them as separate init points - different context windows, a set of keyframes, that kind of thing. It encodes a batch of images individually into a latent video batch where each "video" is a single frame.

That's the whole trick, and it's more useful than it sounds once you start doing long-form work. The Wan ecosystem's answer to the 5-second clip limit is chaining and context windows, and the community's cleanest version of that - parallel keyframe generation - is exactly this: instead of chaining clips sequentially (which piles up degradation), you generate a bunch of images from one source and use them as first/last-frame anchors so every keyframe is only one step removed from the original. To feed those anchors into a WanVideoWrapper graph you need them as latents, and encoding them one-at-a-time as single-frame clips is what this node does.

How it works

A VAE turns pixels into the compressed latent space the model actually samples in. Normally you'd hand it one image. Here you hand it an IMAGE batch and it runs each image through the Wan VAE on its own, producing a LATENT where the batch dimension holds your separate single-frame encodings rather than one continuous clip. Downstream nodes (image-embed builders, add-latent nodes, the sampler) can then pull from that batch as individual init latents.

The inputs and outputs that matter

Two inputs do the real work:

• images (IMAGE) - your batch. However many images you pass in is however many single-frame latents you get out.
• vae (WANVAE) - the Wan VAE, straight from your VAE loader. It has to be the Wan VAE, not an SDXL/Flux one - the latent space is model-specific.

The rest are VAE-tiling knobs - enable_vae_tiling (off by default) plus tile_x, tile_y, tile_stride_x, tile_stride_y. Leave tiling off unless you're encoding large images on a tight VRAM budget and the encode step OOMs; then flip it on and the defaults (272/272 tiles) are a fine starting point. Tiling trades a little speed and, at aggressive settings, a faint seam risk for lower peak memory.

The output is samples (LATENT) - the per-frame batch. Wire it wherever a Wan init latent is expected for your workflow.

How to install it

Easiest path is ComfyUI Manager: search ComfyUI-WanVideoWrapper, install, restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/kijai/ComfyUI-WanVideoWrapper
pip install -r ComfyUI-WanVideoWrapper/requirements.txt

then restart ComfyUI. The node itself downloads nothing extra - but the wider WanVideoWrapper setup does need the Wan model weights (kijai hosts fp8 versions at Kijai/WanVideo_comfy), the Wan VAE, and the UMT5 text encoder in their usual model folders before any of this runs.

Common issues & troubleshooting

Wrong VAE type. If the node errors on connection or spits garbage latents, check you fed it the Wan VAE via a WANVAE loader, not a generic ComfyUI VAE. The types won't even match up if you try.

OOM during encode on big batches. Encoding many high-res images at once stacks VRAM. Turn on enable_vae_tiling, or just feed fewer images per run - this is a batch node, nothing stops you from doing it in two passes.

You expected one clip, got a batch of stills. That's working as intended. Each image becomes a one-frame latent; this is init material for other nodes, not a finished video. If you wanted actual motion you're looking for the sampler, not this.