🐐 Image Tiler

Tiled processing is the standard answer to "my image is too big to fit in VRAM as one pass" - split it into overlapping chunks, process each chunk, then blend the seams back together so it reads as one continuous image rather than a visible grid. Tools like Ultimate SD Upscale and Tiled Diffusion do this for diffusion sampling specifically; Image Tiler is GOAT's own tile-splitting primitive, built to pair with their SamplerTiledContextAdvanced node and Image Untiler for a full custom tiled pipeline, rather than being tied to any one sampling method.

How it works

You set a tile_width and tile_height, and the node cuts the image into that grid. The row_overlap/col_overlap values (both defaulting to a generous 512px) control how much neighboring tiles share - overlap is what gives a later blending step something to work with, so adjacent tiles don't just butt up against a hard seam. row_offset/col_offset shift the whole grid by a fixed amount, which the node's own description calls out as useful for nudging an inconveniently-placed tile boundary away from, say, a face or a straight architectural line where a seam would be most visible.

tiling_mode controls the order tiles come out in - radial, checkerboard, spiral, row, column, diagonal - which matters if whatever you're feeding these tiles into processes them sequentially and benefits from a particular pattern (a radial or spiral order, for instance, would let a context-aware sampler like SamplerTiledContextAdvanced build outward from the center rather than jumping around unpredictably).

Everything about where each tile sits and how it should be reassembled gets bundled into TILE_DATA, which is a pack-specific type - it only flows into GOAT's own Image Untiler or SamplerTiledContextAdvanced nodes downstream, not something you'd construct or read yourself.

Inputs and outputs that matter

• image - the source, typically something large enough that processing it whole is the actual problem you're solving.
• tile_width / tile_height (1–8192, default 1024 each) - your tile size, generally chosen around whatever resolution your downstream processing (a sampler, an upscale model) handles comfortably.
• row_overlap / col_overlap (default 512) - how much adjacent tiles share; this is what makes seamless reassembly possible later.
• tiling_mode (default radial) - the processing order the tiles come out in.

Three outputs: IMAGES (the batch of tiles), TILE_DATA (the bookkeeping bundle Image Untiler and SamplerTiledContextAdvanced need), and TILE_COUNT (a plain int - handy for any loop or batch-size logic downstream that needs to know how many tiles it's dealing with).

How to install it

ComfyUI Manager: search "GOAT Nodes", install, restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/AconexOfficial/ComfyUI_GOAT_Nodes.git

then restart. No models - this is pure geometry, splitting an image into a grid.

Common issues & troubleshooting

Overlap eats more of your image than you expect at small tile sizes. With 512px overlap on 1024px tiles, half of each tile is shared context - reasonable at that scale, but if you shrink tile_width/tile_height down without also shrinking the overlap, you can end up with tiles that are mostly overlap and very little unique content. Scale overlap down proportionally with tile size.

Don't lose track of TILE_DATA. It has to reach whatever you're using to reassemble (Image Untiler) or context-sample (SamplerTiledContextAdvanced) - if your graph drops it somewhere in the middle (say, you batch-process the IMAGES output through a node that doesn't pass side-channel data through), you'll have no way to put the tiles back together correctly.

This node alone doesn't do anything generative. It just splits. If your goal is tiled diffusion - running a sampler per-tile with awareness of the whole image so tiles don't diverge from each other - you need SamplerTiledContextAdvanced in between this and Image Untiler, not a plain sampler on each tile independently.