An outpainting tool whose real engineering is hiding the seam

Outpainting, plus a whole 2D game-art studio built on the same pipeline

Image Extender is a small open-source web app that does two things under one roof: it extends any photo in any direction using Google's Gemini image models through OpenRouter, and it reuses that same underlying extension pipeline to generate whole sets of 2D game art, parallax backgrounds, autotile sets, sprite animations and decoration props, from one shared studio interface.

The README frames the core problem plainly, and it is a real one for anyone who has tried AI outpainting casually: the seam between the original photo and the newly generated region is usually visible, sometimes subtly and sometimes not, showing up as a colour shift, a lighting mismatch, or a texture that does not quite continue. The project's actual engineering effort goes into making that seam disappear rather than into the image generation itself, which it delegates entirely to Gemini through OpenRouter. That focus, treating seam quality as the hard problem worth solving carefully rather than an afterthought, is the right place for a small open-source project to put its effort, since the generation model itself is not something this project could meaningfully improve on.

A four-step pipeline built specifically to hide the seam

The README documents the extension pipeline as four sequential stages, and each one earns its place by fixing a specific, named failure mode rather than existing for its own sake. The canvas is expanded with a blank region in the chosen direction, Gemini outpaints that blank area, the result is pre-corrected for low-frequency colour drift toward the original image at the seam, and only then is a Poisson blend applied with a grown mask to make the boundary mathematically invisible.

The pre-correction step is the detail that shows real attention to how outpainting actually fails in practice. The README names the specific symptom it targets, describing it as "the sky got slightly bluer," a subtle, global colour shift between the original and generated regions that a naive blend would preserve rather than fix. Poisson blending, based on the well-known 2003 gradient-domain image editing technique from Pérez, Gangnet and Blake, is excellent at hiding a sharp boundary, but it works on gradients, not on a slow colour drift across the whole generated region, so correcting that drift first is a necessary step the blend alone cannot substitute for. Running the horizontal pipeline up to three times in parallel at different temperatures, then measuring the seam residual of each result and presenting the best-blended candidate first, is the best-of-3 picker the README's own description leads with, and it converts an unreliable single attempt into a small, ranked set a user can actually choose from.

Two orders of QA, chosen to fit two different jobs

The README describes what it calls an AI "art director" pattern used across two of the studio's modes, and the detail worth noting is that the two implementations run in opposite directions for a considered reason rather than by accident. Props generation runs the pattern forward: a reasoning model first decides what to make, and an image model renders that decision afterward. Tile generation runs it in reverse: the image model generates first, and a vision model reviews the composited result, sending a concise fix report back for a repaint only if something is actually wrong, with the best result of that loop kept regardless of how many repaint passes it takes.

Sprite generation abandons the vision-critic pattern entirely in favour of deterministic post-process checks, scale normalisation, baseline grounding, horizontal centring, and a pixel-level detector for duplicated or spilled-over content that forces a repaint on a real, measurable defect. The README is explicit about why: this keeps sprite generation fast and predictable rather than blocked on a QA model's judgement call. Matching the QA strategy to what each asset type actually needs, generative judgement for props, corrective review for tiles, and hard deterministic checks for sprites where a mechanical property can be measured directly, is a more considered design than applying one QA pattern everywhere out of consistency for its own sake.

Bring your own key, and the server genuinely forgets it

The project's privacy architecture is stated plainly and is worth taking at face value because it is specific rather than a general assurance. The OpenRouter API key a user enters in the interface is stored only in the browser's own local storage, is never written to the server's disk, and is never logged; the server uses it once per request purely to proxy the call to OpenRouter and then discards it. An optional server-side environment variable can supply a fallback key for requests that arrive without one of their own, which is useful specifically for someone hosting a public demo who wants visitors to be able to try it without first getting their own key, but that fallback is explicitly optional rather than the default path.

That architecture is the correct one for a tool that needs a paid API credential to function at all. A server that stores or logs a user's key, even briefly, becomes a place that credential can leak from later, whether through a bug, a compromised log file, or simple negligence. Never persisting the key anywhere the server controls removes that entire class of risk by construction, and stating explicitly that there is no analytics, no telemetry and no tracking closes the remaining question of what else the server might be quietly recording about a user's activity.

Getting it running, and what it actually costs to use

Setup is an ordinary local Next.js development flow:

git clone https://github.com/boona13/image-extender.git
cd image-extender
npm install
npm run dev

On first load the app prompts for an OpenRouter key, which is entered once and then remembered in the browser until manually cleared from settings. The README states plainly what that key will actually cost to use: roughly three cents per extension using the default fast image model, which is a concrete, checkable number rather than a vague reference to affordability, and it lets a prospective user do the arithmetic on their own expected usage before deciding to try it at all.

The model picker exposes several backing models with different cost and speed trade-offs, including a fast default, a higher-fidelity variant, an older baseline, and a separate high-fidelity option from a different provider described as noticeably slower, alongside a lighter reasoning and vision model used specifically for the scene-brief distillation and the QA review passes described earlier, so the more expensive generation models are reserved for the actual pixels while the cheaper model handles judgement calls.

What to weigh before adopting it

The configuration knobs the README documents are worth knowing about even for a casual user, because several of them materially change output quality rather than being cosmetic settings. The percentage of canvas each extension adds, the number of best-of-N candidates attempted per horizontal extension, how many extra repaint passes the tile QA director may trigger, and the pixel radius the Poisson mask is grown into the original image before blending are all named constants in specific source files, which means a user who wants to trade generation cost against seam quality has an actual, documented lever to pull rather than needing to read the source from scratch to find one.

The project is MIT licensed, which is permissive and allows commercial use, and reports 1,108 stars, 131 forks and a single open issue, with the last push on 2026-05-31. It depends entirely on OpenRouter's continued access to the underlying Gemini image models, so its usefulness is tied to that access remaining available and reasonably priced rather than to anything this project controls on its own.

Before adopting it, three steps in order. Get an OpenRouter key and budget for the roughly three-cent-per-extension cost the README states, since nothing here is free once you move past a first look. Decide whether you want the browser-stored key or the optional server-side environment fallback, since the two serve different situations, personal use against hosting a demo for others. And if seam quality on a specific kind of image matters to your use case, read the configuration knobs table before assuming the defaults are already tuned for it, since several of them exist specifically to be adjusted.

Editorial conclusion

Image Extender fits anyone who wants AI outpainting where the seam actually disappears rather than merely blends, and its five-workspace studio built on the same extension pipeline, parallax layers, autotiles, sprite sheets and decoration props, gets meaningfully more out of one core technique than a single-purpose outpainting tool would. Its real engineering sits in the unglamorous middle of the pipeline, correcting colour drift before blending and matching each asset type's QA strategy to what it actually needs, forward reasoning for props, reverse critique for tiles, deterministic checks for sprites, rather than in the image generation itself, which it correctly leaves to Gemini. Budget for the roughly three-cent-per-extension cost the README states, choose between the browser-stored key and the optional server-side fallback based on whether you are using it personally or hosting it for others, and read the configuration knobs table if seam quality on a specific kind of image matters enough to be worth tuning.

Frequently asked questions

Official sources

1. boona13/image-extender on GitHub
2. Issues
3. License: MIT
4. Project website
5. README