WanAnimatePlus Decode
Turning latents back into video frames
- vae
- samples
- images
Every Wan workflow ends the same way: the sampler hands you latents, and something has to turn those latents into the images you can actually look at. That's WanAnimatePlus Decode. It's the fork's rename of the wrapper's decode node, and it does one job - VAE-decode a LATENT into an IMAGE sequence - with enough VRAM engineering bolted on that it's worth knowing which levers do what.
The levers that matter. The node's whole personality is tiled decoding. enable_vae_tiling is off by default, and the tooltip is unusually honest about the tradeoff: tiling "drastically reduces memory use but will introduce seams at tile stride boundaries." If you're on a 12GB card decoding 81 frames at 832x480, you'll probably need it. If you're on a 24GB+ card, leave it off and enjoy seam-free output.
When tiling is on, four numbers control the grid: tile_x/tile_y (default 272 each) set tile size, and tile_stride_x/tile_stride_y (defaults 144/128) set how far each tile jumps. Bigger tiles, fewer seams. The tooltip even gives you the practical rule of thumb: seams become "barely noticeable at 2x stride size" - so with a 320 tile you want a 160 stride. The instinct to shrink everything to save VRAM is exactly backwards here; smaller tiles save memory but make the seams scream, and you pay for it in visible grid artifacts on flat surfaces.
What you can leave alone. normalization (default default) has three options - default, minmax, none - and unless you're chasing some edge case with clipped values, the default is right. The real inputs are vae (your WanAnimatePlus VAELoader output) and samples (whatever your WanAnimatePlus Sampler - or SamplerFromSettings - produced). Output images goes to your video preview or save node.
The classic gotcha: frame count. If your decoded clip comes back shorter than you asked for, that's not this node's fault - it's the Wan VAE's 4x temporal compression and the 4n+1 arithmetic that follows (111 frames in becomes 28 latents and decodes back to 109 unless you pad). People blame the decode node for this constantly. Check your num_frames against the 4n+1 requirement before you start debugging tiles.
Install via ComfyUI Manager (search "WanAnimatePlus") or git clone https://github.com/wuwukaka/ComfyUI-WanAnimatePlus into custom_nodes, restart. Keep the whole chain on WanAnimatePlus nodes - this decode expects latents shaped by the fork's sampler, and mixing in the original wrapper's decode is a classic source of "my frames look wrong" posts.
Inputs (8)
| Name | Type | Default | Description |
|---|---|---|---|
| vae | WANVAE | — | |
| samples | LATENT | — | |
| enable_vae_tiling | BOOLEAN | false | Drastically reduces memory use but will introduce seams at tile stride boundaries. The location and number of seams is dictated by the tile stride size. The visibility of seams can be controlled by increasing the tile size. Seams become less obvious at 1.5x stride and are barely noticeable at 2x stride size. Which is to say if you use a stride width of 160, the seams are barely noticeable with a tile width of 320. |
| tile_x | INT | 27240–2048 | Tile width in pixels. Smaller values use less VRAM but will make seams more obvious. |
| tile_y | INT | 27240–2048 | Tile height in pixels. Smaller values use less VRAM but will make seams more obvious. |
| tile_stride_x | INT | 14432–2040 | Tile stride width in pixels. Smaller values use less VRAM but will introduce more seams. |
| tile_stride_y | INT | 12832–2040 | Tile stride height in pixels. Smaller values use less VRAM but will introduce more seams. |
| normalizationopt | COMBO | 3 options: default, minmax, none |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| images | IMAGE | — |