🧩 Split Tile

Split Tile chops an image into a grid of overlapping tiles and hands you the geometry needed to put them back together later. It's the DIY building block for tile-based workflows - the kind of thing that lets you upscale a huge image on a small GPU, or run a detail pass per-region, without every tile having visible seams where they meet.

That's a real, well-established pattern in this community: the standing answer to "print sizes, 4K+, limited VRAM" is exactly this - split into tiles, process each one, blend the seams back together. Tools like Tiled Diffusion and Ultimate SD Upscale automate the whole loop for you inside a KSampler. Split Tile doesn't try to be that - it's the raw split step, paired with its sibling Stitch Tile for the reassembly, and everything in between (what you do to each tile) is up to you. That's genuinely more flexible: you can run a different model per tile, inspect tiles individually before committing, or feed them through a ControlNet-Tile-guided sampler yourself.

How it works

Given a target tile size and how much neighboring tiles should overlap, Split Tile lays a grid over the image and cuts it into pieces. The overlap matters more than it looks: without shared edge pixels between tiles, you have no way to blend the seam later, and you'd get a visible patchwork grid on the reassembled image. force_uniform_tiles keeps every tile the exact same size (padding the ones that fall off the edge of the image) rather than letting edge tiles come out smaller - the pad_mode/pad_value pair controls what fills that padding: repeat the edge pixels, mirror them, or use a flat color.

Because both outputs are lists, ComfyUI will run whatever you connect downstream once per tile automatically - you don't need to build a loop yourself.

Inputs and outputs

• image (IMAGE, required) - the source image to split.
• tile_width / tile_height (INT, default 512, up to 8192) - how big each tile is. Bigger tiles mean fewer of them and less seam-blending work, but more VRAM per tile when you run something heavy on each one; smaller tiles are cheaper individually but multiply fast.
• overlap (INT, default 64) - how many pixels neighboring tiles share. This is what Stitch Tile blends across later - too little and you'll see grid lines, too much and you're reprocessing the same pixels repeatedly for no benefit.
• force_uniform_tiles, pad_mode, pad_value - mostly leave on defaults; these only matter when the image doesn't divide evenly into whole tiles.
• tiles (IMAGE list) - the individual tile images, feed these into whatever your per-tile step is.
• stitchers (TILE_STITCHER list) - the bookkeeping Stitch Tile needs to paste everything back in the right place. Carry this alongside the tiles list, untouched.

Common issues

Keep tiles and stitchers in lockstep. The pairing is positional - index 3 in tiles corresponds to index 3 in stitchers. If you run a filtering or reordering node on the tiles list without doing the identical operation to the stitchers list, Stitch Tile will paste tiles into the wrong slots.

Small tiles on a big image means a lot of re-execution. Since every downstream node runs once per tile, a workflow that felt instant on one full image can suddenly run dozens of times per generation. Budget for that before you crank tile_width/tile_height down.

This isn't the same thing as the Tiled Diffusion node the pack's README lists as a recommended companion install. That one automates tiled sampling inside a KSampler for VRAM-limited generation. Split Tile is a manual, two-node primitive you compose yourself - no extra dependency required beyond the base pack.