FL Image Slicer

FL_ImageSlicer does one thing and does it cleanly: it chops an image into a grid of equal rectangular tiles and hands them back as a batch. That's it. No blending, no overlap, no reassembly - a knife, not a Swiss Army knife. Which is exactly what you want when you're building a tiling workflow and need the "cut it up" step to be predictable and boring.

You'd reach for it when you want to process regions of an image independently - run something on each tile, or lay them out as a grid, or feed slices into a per-region step - and then recombine downstream. It's the front half of a tile pipeline.

How it works

You tell it how many columns (width_subdivisions) and rows (height_subdivisions) to divide into, and it cuts the image into that many equal cells, walking left-to-right, top-to-bottom. A 3×2 gives you 6 tiles in reading order. All the tiles come out as a single IMAGE batch, so whatever you do next processes them together and keeps their order. Because the order is deterministic, you can reliably reassemble them later with a batch-to-grid node.

Note it slices into equal divisions - it's a clean grid cut, not a smart content-aware split. Predictability is the feature.

The inputs and outputs

• image - the image to slice.
• width_subdivisions - number of columns (1–100).
• height_subdivisions - number of rows (1–100).

Output is a single IMAGE batch containing every tile, in left-to-right, top-to-bottom order. Feed it into whatever processes a batch; recombine afterward if you need the whole image back.

Installing it

Ships in the Fill-Nodes pack. ComfyUI Manager: search ComfyUI_Fill-Nodes, install, restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/filliptm/ComfyUI_Fill-Nodes

then restart. The pack prints its "Machine Delusions" splash banner on startup - that's just the author's logo, nothing to worry about.

Where people get tripped up

• It cuts, it doesn't stitch. There's no reassembly built in. If you slice, process, and want the full image back, you handle the recombine yourself - the pack's grid/batch nodes can do it, and the deterministic ordering is what makes that reliable.
• No overlap means visible seams if you're doing generative work per tile. For a plain crop-and-lay-out job, fine. But if you sample or upscale each tile separately and then glue them back, hard edges between tiles are on you - overlapping-tile samplers exist precisely to avoid that. This node gives you clean, non-overlapping cuts, which is the wrong tool for seamless generative tiling and the right one for straightforward tiling.
• Slices are equal divisions. If your image doesn't divide evenly by your subdivision counts, don't expect content-aware boundaries - it's a uniform grid. Pick subdivision counts that make sense for your dimensions.
• Big subdivision counts make big batches. 10×10 is 100 tiles in one batch; whatever you run on them runs 100 times. Keep an eye on that if the downstream step is heavy.