Nodes/ComfyUI-SplitImage/Calculate Tiling Spec
ComfyUI Node

Calculate Tiling Spec

Compute your tile grid without touching an image — the spec calculator

By QuigleyDown·Created 5 months ago·Updated 5 months ago· 0
Calculate Tiling Spec
    • tiling_spec
    • tile_width
    • tile_height
    width512
    height512
    rows2
    columns2
    overlap64

    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_height ahead 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.

    CategorySplitImage

    Inputs (5)

    NameTypeDefaultDescription
    widthINT5121–16384
    heightINT5121–16384
    rowsINT21–100
    columnsINT21–100
    overlapINT640–1024

    Outputs (3)

    NameTypeDescription
    tiling_spec*
    tile_widthINT
    tile_heightINT