Tile Decode & Assembly

The moment your generator hands you a latent that's too big for the VAE to decode in one go, you have two options: watch it OOM, or decode in tiles. Tile Decode & Assembly is the "just do it all" version - it takes a latent that's been split into tiles, VAE-decodes each tile, stitches the full image back together, and saves you the three-node stack most people build by hand.

What it collapses

Read the pack source and the description is blunt about it: this node replaces VAE Decode (Tiled), IMAGE_LIST_TO_BATCH, and Tile Assembly all in one. If you've built a tiled decode graph before, you know the drill - decode each tile, batch them back up, then reassemble using position metadata. That's exactly the plumbing this node bundles so you don't have to lay the wires yourself.

It's designed to sit downstream of Tile Split [Eclipse]: that node outputs the tile latent samples plus a tile_pipe carrying each tile's position and the original canvas size. You feed the samples, your VAE, and that pipe in here, and out comes the reconstructed full image.

The inputs that matter

• samples (LATENT) - the tiled latent samples from your sampler. It accepts both a batch and a list, and auto-converts a list to batch, so you don't have to worry about which shape your tiled sampler emitted.
• vae - the VAE used for the tiled decode.
• tile_pipe - the position/grid metadata from Tile Split. Without this, the node can't know where tiles belong.
• tile_size - default 0 means "auto from the pipe", which uses the tile's own dimensions and is described as optimal (no internal re-tiling). Set it manually to force smaller decode tiles - e.g. 512 for SD/SDXL, 1024 for Flux2 - when you need to squeeze VRAM further.
• overlap - 0 means auto (tile_size // 8, minimum 32). Only kicks in when you've forced tile_size smaller than the tile dimensions. More overlap = less color banding, more VRAM.
• padding - the gradient blend width at tile seams (default 128). This is what hides the seams when tiles are stitched back together.

The single output is image: the reconstructed full image. If you see visible seams, bump padding; if you see banding at tile boundaries, raise overlap. Both are quality-vs-VRAM dials and it's worth a couple of test runs to find your sweet spot.

Why tiled decode exists at all

VAE decode is the sneaky VRAM hog of image generation - decoding a big latent to pixels can spike memory far beyond what the sampler itself used. Tiling the decode keeps the peak down by only materializing one tile's worth of pixels at a time. That's the whole game, and it's the same reason tiled VAE is a standard feature in upscaling workflows for limited-VRAM cards. On a big GPU you can often skip it; on a 6–8GB card it's the difference between running 4K output and not.

Install it

Part of ComfyUI_Eclipse. ComfyUI Manager → search "Eclipse" → Install → restart, or:

cd ComfyUI/custom_nodes
git clone https://github.com/r-vage/ComfyUI_Eclipse

The usual pack dependencies apply (opencv-python, pilgram, PyYAML, aiohttp; portable installs may need pip install -r custom_nodes/ComfyUI_Eclipse/requirements.txt). It's under Eclipse → Image → Transforms.

Gotchas

The #1 mistake is connecting a tile pipe from a Tile Split that doesn't match the latent you're decoding - different grid, different positions, wrong image. Rebuild the split and decode together and they'll agree. Also, if you leave tile_size at auto and the source tiles are already huge, you get zero VRAM relief; auto is "optimal" for quality, not for memory. Force a smaller tile_size when the card is actually the bottleneck.