Merge List of Tiles to Image

If you split an image into tiles, run each tile through a sampler, and then just paste them back on a grid, you'll see seams - visible edges where each tile's processing disagreed with its neighbor. Merge List of Tiles to Image is the "stitch" half of the tiling pair (its partner, SplitImageToTileList, is the "cut" half), and its job is to reassemble tiles into one image without those seams.

How it works

It reconstructs the image onto a blank canvas using the same tile geometry that SplitImageToTileList produced - same overlap, same row-major order, same edge-anchoring - so the two nodes are designed to be exact inverse operations. The seamlessness comes from a weighted-blend scheme:

• In the overlap regions, where two or more tiles cover the same pixels, the tiles are blended with a sinusoidal feather mask. Each tile contributes with a weight that fades toward its edges, so no single tile's boundary is visible - the transition is a smooth cross-fade instead of a hard cut.
• The canvas accumulates each tile times its weight, then divides by the total weight per pixel, which is a proper weighted average. Edges and corners end up fully covered because the blend normalizes.
• If overlap is 0, there are no shared pixels and no feathering - it's a plain paste, which means hard seams if your per-tile processing diverged. For clean merges you want overlap > 0, which is why the splitter defaults to 128px.

The inputs that matter

• image_list - the list of tiles to merge. This is a list input; wire it straight from the split node (or from per-tile processing downstream).
• final_width (default 1024, 64–32768) and final_height (default 1024, 64–32768) - the dimensions of the output image. Set these to the target size of your final image. This is the one you'll actually think about: if your per-tile pass upscaled each 1024 tile by 2×, the final should be 2× the original width/height, not the original.
• overlap (default 128, 0–4096) - must match the overlap you split with. Get this wrong and the tile layout won't line up.
• Output: one IMAGE, the merged reconstruction.

Gotchas

• final_width/final_height are your responsibility. The merge can't infer the output size from the tiles alone - it trusts these values and uses the tile layout to fill them. Wrong target size → tiles pasted off-center or clipped at the edges. If your processing didn't change resolution, use the original image's dimensions.
• Overlap mismatch = broken layout. The merge reconstructs assuming the same geometry as the split. If you merge tiles that were split with 64px overlap but tell the merge node 128, the seam positions won't line up and you'll get overlapping or gappy regions.
• Tile order is sacred. The merge walks the tile list in order, matching each to its grid slot. Shuffle, drop, or re-sort the list and the image comes out scrambled.
• Feathering depends on overlap. With overlap 0 you get no cross-fading, so any brightness or detail disagreement between tiles shows up as hard seams. Keep overlap > 0 for processed tiles.

The honest limitation

This node does the geometry and blending, but it can't fix the content disagreements that cause seams in the first place - if your per-tile pass shifted colors or composition, the blend just softens the boundary. The real fix is upstream (keep denoise low, use a tile-condition like ControlNet Tile, keep prompts consistent across tiles). For the mechanics, though - splitting, processing, stitching - these two core nodes are the whole toolkit.

Ships with ComfyUI core (recent addition, update if missing). No models, no install. Cut, process, stitch - and the seams stay quiet.