Guides

    Splitting a four-up grid into usable assets

    A 2x2 variation grid is one file, not four assets. How to slice it into individual images you can actually upscale, animate, or drop into a timeline.

    Versely Team8 min read

    You ask for four variations and get back a single image with four pictures arranged in it. Visually that's four options. Operationally it's one file, and one file is one asset. You can't post a quadrant. You can't run a quadrant through an upscaler. You can't hand a quadrant to an image-to-video model as a first frame. Until the grid is cut, every one of those four ideas is stuck behind the same JPEG.

    split_image_grid is the unglamorous tool that fixes this. It takes an image plus a row count and a column count, and returns each cell as its own image.

    It's a slice, not a model call

    This is the first thing to internalise, because it determines both how reliable the tool is and how you have to use it.

    The split is deterministic. It is not a vision model looking at your picture and working out where the tiles are. You tell it the grid is 2 by 2, or 3 by 3, and it cuts on those lines. All three parameters are required for exactly this reason: there's no detection step to fall back on if you leave one out.

    The upside is that it's completely predictable on a real grid. The downside is that it's confidently wrong on anything that only looks like one. A 2×2 instruction against a 3×3 contact sheet doesn't fail with an error, it slices straight through the middle of six tiles and hands you four ruined images. Splitting a grid image into separate images documents the parameter set, and the discipline it implies is simple: count the tiles before you type the numbers, and count them off the image rather than off your memory of what you asked for.

    Sources that split cleanly:

    • A 2×2 variation grid from a single generation
    • A supplier's product sheet with an even number of items in even rows
    • A contact sheet exported with consistent cell sizes

    Sources that don't:

    • An irregular collage with different-sized panels
    • Tiles separated by uneven margins
    • Anything with a caption strip or header band along one edge

    The pixel cost nobody accounts for

    Each tile is a fraction of the original's resolution, and the fraction is exactly what the arithmetic says. A 1024px 2×2 grid yields four 512px images. That's frequently too small to publish as-is, and it's the single most common reason a split feels like it didn't work.

    Source grid Layout Per-tile share Typical next step
    1024px 2×2 1/4 of the pixels Upscale before anything else
    2048px 2×2 1/4 of the pixels Often usable for social directly
    1536px 3×3 1/9 of the pixels Also 512px a tile — upscale before anything else

    So the real workflow isn't "split and ship." It's split, triage, then upscale only the survivors. Which brings us to the step people skip.

    Triage before you spend

    A four-up grid almost never contains four keepers. Usually one is good, one is arguably good, and two are obviously not. The whole point of generating variations was to produce candidates, so treating all four as deliverables misunderstands what you asked for.

    Do the discard pass immediately after the split, while the four are side by side and comparison is easy. Everything you carry forward from here has a cost attached — the upscale, the animation, the edit — and carrying a tile you were never going to use means paying that cost for nothing.

    A workable triage rule for a variation grid:

    1. Reject on structure first. Bad hands, broken product geometry, illegible label, wrong number of objects. These are not fixable downstream and no amount of upscaling rescues them.
    2. Then reject on framing. If the subject sits where your target crop will cut it, that tile is a losing starting point even if it's the prettiest one.
    3. Keep at most two. One primary and one alternate is enough. If three genuinely tie, you asked a question the grid couldn't answer and you're better off generating again with a tighter brief than upscaling all three.

    Where each keeper goes next

    Once a tile is its own file, it re-enters the pipeline as a normal image, and that's the actual payoff. Four things become available that weren't:

    Upscale it. This is the usual immediate next step, precisely because of the resolution math above. Upscaling image resolution covers the mechanics, asking the agent to upscale an image covers the conversational path, and upscaling covers what it can and can't recover. Upscaling is a real generation and is billed per the model you pick, which is why the triage pass belongs before it and not after.

    Animate it. A tile is a valid input for image-to-video, which means the good quadrant of a still grid can become a clip. Turning a photo into a video is the shortest route. Worth doing the upscale first if the tile is small, since a low-resolution input doesn't get better on its way through a video model.

    Edit it further. The tile can go back into image-to-image as a source, which is how you fix the one thing that was wrong with an otherwise-good variation without regenerating the whole grid. Editing a photo with AI is the same path.

    Put it in a timeline. Individual images can be held on screen for a set duration and stitched with clips into a single video, which is what turns four variations into a four-beat sequence rather than four separate posts.

    What gets sliced along with the picture

    Two things to check on the source before you cut, both of which show up in the output rather than as an error:

    Borders and gutters. If the grid had visible dividing lines or a border, those get sliced too and end up as edge artefacts on the individual tiles. Trim or upscale afterwards to clean it up, but notice it first.

    Caption strips. A sheet with a header, a watermark band, or per-tile labels underneath will not have those elements neatly separated by an even split, because they aren't part of the even grid. If the source has one, the split lines won't land where you want them.

    The general shape of the limitation: the tool cuts an even grid at the counts you supply. Anything that isn't evenly gridded needs to be handled before the split, not after.

    The order that actually works

    Putting it together for a typical variation grid:

    "This is a 2x2 grid of variations — split it into four separate images."

    Four files come back. Look at them, discard the two that don't work, then:

    "Upscale the top-right one, then animate it with a slow push in."

    Two charges on one asset, rather than four charges spread across assets you'd already decided against. If you're doing this at scale across a product catalogue, what 100 AI product images comes to is the useful reference point, since the upscale rather than the split is where the spend lives. The whole family of cleanup and enhancement operations lives under the enhance group if you want to see what else attaches to a finished still.

    FAQ

    Will it detect the grid automatically if I don't know the dimensions?

    No. Rows and columns are both required and there is no detection pass. This is a deliberate trade: a deterministic slice is completely reliable when you give it the right numbers and completely wrong when you don't. Count the tiles off the image itself before running it.

    Can I split a grid that has different-sized panels?

    Not usefully. The tool cuts on an even grid, so an irregular collage or a layout with one large panel and several small ones will get cut on lines that don't match the actual panels. For those, the workable approach is to treat the source as an image to crop rather than a grid to split.

    Is splitting a grid expensive?

    It's a deterministic slice rather than a generation, so it's a lightweight image operation. The spend that follows it is almost always the upscale, which is billed according to the model you choose. That's the number worth checking before you run it across every tile, and the agent can estimate the total for a planned batch before anything is dispatched.

    My tiles came out too small to use. What went wrong?

    Probably nothing — that's the expected arithmetic. A 2×2 split gives each tile a quarter of the source pixels, so a 1024px grid produces 512px tiles. The fix isn't a different split, it's either generating the grid larger in the first place or upscaling the one or two tiles you're keeping. Generating larger is the better move if you know in advance that the tiles are the deliverable.