Calculate Tiling Spec
Compute your tile grid without touching an image — the spec calculator
- tiling_spec
- tile_width
- tile_height
This is the pack's "headless" node: it calculates a tiling configuration without ever seeing an image. You give it a width, a height, a grid, and an overlap, and it hands back a tiling_spec plus the exact tile_width and tile_height you'll get. Nothing is split here - it's pure arithmetic, the same math the split nodes run internally, exposed so you can plan and reuse a grid instead of letting each split figure it out on the fly.
What it computes
Give it the target image width and height (defaults 512, max 16384), your rows and columns (1–100), and overlap in pixels (default 64, max 1024). It returns:
- tiling_spec - a small dict (
rows,columns,overlap,tile_w,tile_h,orig_w,orig_h,padded_w,padded_h) that Stitch Image Tiles can read directly. - tile_width / tile_height - the exact tile size, so you can sanity-check what each tile will cost before you commit.
The formula it uses is worth understanding because it drives the whole pack: tile = ceil((dim + (n-1) * overlap) / n). Notice what that does - the overlap you set is added into the covered area, not subtracted from the image. Each tile is a bit bigger than dim/n, and neighbouring tiles share overlap pixels of content. That's deliberate: it means the grid always covers the full image plus a margin, and the stitch node's blending ramps have real pixels to work with.
When it's actually useful
Split Image into Tiles already outputs a spec for free, so this node isn't needed in a plain split → process → stitch chain. It earns its place when you want the geometry separate from the split:
- You're processing a folder of same-size images and want one fixed grid rather than whatever each split decides.
- You're building a workflow where the split happens in one pack and the stitch in another, and you want a single source of truth for rows/columns/overlap.
- You're planning VRAM before running anything - knowing
tile_width/tile_heightahead of time lets you eyeball whether one tile fits before you OOM.
Honestly, for most people this node never gets touched. It's a planning tool, and that's fine. Its real value is the tiling spec being a data object you can thread through a graph instead of re-typing grid settings in three places.
Installing it
Via ComfyUI Manager (search "ComfyUI-SplitImage") or:
cd ComfyUI/custom_nodes
git clone https://github.com/QuigleyDown/ComfyUI-SplitImage.git
Then restart ComfyUI. No dependencies, no model files - it's just math and torch, both already in ComfyUI.
Gotchas
The main trap is treating this as a substitute for the split node. It isn't - it only computes. If you change rows/columns/overlap here without changing the matching Split Image into Tiles node, the spec you feed the stitch node will silently disagree with the tiles you actually produced, and stitch will throw its "total tiles not divisible by rows*cols" error. Keep the numbers mirrored, or just skip this node and let the splitter emit its own spec.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| width | INT | 5121–16384 | — |
| height | INT | 5121–16384 | — |
| rows | INT | 21–100 | — |
| columns | INT | 21–100 | — |
| overlap | INT | 640–1024 | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| tiling_spec | * | — |
| tile_width | INT | — |
| tile_height | INT | — |