VAE Encode (Tiled)

VAE Decode (Tiled) is famous for saving video renders; its quieter sibling does the same thing in the other direction. VAE Encode (Tiled) pushes an image into latent space in overlapping chunks instead of all at once, so img2img and inpainting can start from a giant source image your GPU couldn't otherwise touch. If your hi-res source is 4K and your card is 8GB, this is the node that lets the workflow exist at all.

Inputs:

• pixels - the IMAGE to encode.
• vae - your VAE.
• tile_size - default 512. Pixel size of each encode chunk.
• overlap - default 64. Chunk overlap for seam blending.
• temporal_size / temporal_overlap - defaults 64/8, only used for video VAEs (see the tooltips): chunks the frame dimension when encoding video frames. A video VAE compresses time as well as space, so it needs the same frame-chunking treatment on the way in as it gets on the way out.

The output is a LATENT, shaped exactly like one from the plain VAE Encode - same channel count, same 8× spatial compression - which means anything downstream (a sampler, an inpaint encode) treats it identically. You don't need to tell the rest of the graph it was tiled.

When you actually need it

• Huge sources into img2img. A 3072×3072 reference photo through the plain VAE Encode will OOM a mid-range card; tiled, it encodes in the same chunks that let the sampler handle big latents.
• High-res inpainting chains. The crop-edit-stitch and hi-res workflows often re-encode large regions; tiled encode keeps that step honest on limited VRAM.
• Video encode for video-to-video. Loading a long clip, encoding it with the temporal params chunking frames, then conditioning - the mirror of the tiled-decode video workflow.

The catches

• It's the less-common half, and usually the less-necessary one. Encode is cheaper than decode in most VAE implementations, so on many setups plain VAE Encode handles sources that plain VAE Decode couldn't render. People bolt this node in preemptively and often didn't need it. Try the plain node first; reach for tiled only when it actually OOMs.
• Same seam trade as tiled decode. Chunks encoded separately can produce faint tile boundaries in the latent, which show up as subtle texture discontinuities after sampling - worse the smaller your tiles and the bigger your gradients. Overlap 64 with tile 512 keeps it mostly invisible.
• The temporal params do nothing on image VAEs. If you change them and see zero effect on a still, that's correct behavior, not a bug.

If both tiled encode and tiled decode are in your graph, you've built the memory-safe version of a pipeline - slower, slightly softer at the seams, but runnable on hardware that would otherwise refuse to work at that size. On a 24GB card you don't need it; on a 3060 it's the difference between a workflow and an error.