Adding Pixellab Revision Support to Pixelkiln

Revisions were the one thing pixelkiln couldn’t do without a second piece of software running, until five releases changed that while I was still writing about something else.

I went back into pixelkiln’s CHANGELOG last week to grab a version link for the last post and found five releases sitting past the cutoff I’d used before: 0.49.0 through 0.53.0. Four of them landed within the same 24 hours; the fifth, the day before that. I read all five PRs before writing anything, because the one in the middle of the batch looked bigger than a changelog line usually lets on.

None of this made it into the first month recap or the agent skill post, and it should have, at least the first one. It’s the closest thing to a real gap the project has closed since launch.

Revisions used to mean running ComfyUI too

A revision in pixelkiln is a dependent edit to an asset that already exists: image-to-image, inpaint, or outpaint, against a parent that has to pass its own gate before the child can even re-plan. Since launch, that only worked through a self-hosted ComfyUI instance. PixelLab, the provider most people configure on day one because it needs nothing more than an API key, could generate new assets from scratch but couldn’t touch one that already existed.

0.49.0 (PR #166) wires masked inpainting and whole-image editing into revision support through PixelLab’s own /inpaint-v3 and /edit-images-v2 endpoints. A revision asset can now point at PixelLab the same way it already pointed at ComfyUI. The manifest-side gate, requiring the parent to pass before the child re-plans, doesn’t change at all; the mechanics of both are covered in the skill’s revisions reference.

The PR’s own description is honest about what it hasn’t measured yet: where PixelLab doesn’t publish a rate for the new endpoints directly, the cost figures are borrowed estimates from PixelLab’s other image-tier endpoints, called out as estimates rather than dressed up as fact. That’s the same habit the project had in the first month: flag what’s unmeasured instead of rounding it off to something clean.

The CLI side of trying one hasn’t changed either. Plan first, generate against an explicit budget, audit after:

pixelkiln plan
pixelkiln gen --budget pixellab=1
pixelkiln audit --check

pixelkiln plan
pixelkiln gen --budget pixellab=1
pixelkiln audit --check

Two generators that close real gaps

The next two releases each add a PixelLab generator that didn’t exist before, and each closes a gap that was already visible in what the existing generators couldn’t do.

0.50.0 (PR #179) exposes create-tiles-pro‘s shape and building-kit sub-parameters, controls that already existed on PixelLab’s side but weren’t reachable from a pixelkiln manifest. The same PR fixes a real bug along the way: tileSize‘s max was set to 256 when PixelLab’s actual ceiling is 128.

0.51.0 (PR #180) adds a new terrain generator wrapping PixelLab’s /create-tileset endpoint, for two-terrain elevation Wang tilesets: grass blending into water, a floor blending into a cliff edge. tiles‘s own tileFeature: "tileset" option doesn’t cover this case; it’s a different endpoint with a different output shape, which is why it shipped as its own generator instead of a new flag on the old one.

0.52.0 (PR #181) adds imagePro, wrapping /generate-image-v2, PixelLab’s Pro image tier. It’s real style transfer and canvases that don’t have to be square or capped at the smaller default size, at a flat cost of 40 generations the PR describes as already measured against PixelLab’s own billing, not estimated from a neighboring endpoint the way the revision work above had to be.

The gallery closes the loop

0.53.0 (PR #182) is the smallest release of the five and the one that changes the day-to-day workflow the most: the gallery’s asset drawer gets a “+ New revision” action that creates an image-to-image revision without hand-editing the manifest first. Paired with 0.49.0’s PixelLab support, that’s the whole path now: open an asset, ask for a revision, generate it, all in the browser, with no ComfyUI instance and no manifest edit.

The same PR fixes a pre-existing regex bug in addAssetForm‘s id-pattern validation, caught by a new smoke-test flow written to cover the revision button itself. That’s as good an argument for writing the smoke test as the feature it was built to test.

The throughline across all five releases is the one from the last two posts: close the gap between what PixelLab’s API can actually do and what pixelkiln exposes, and say plainly when a number is measured versus borrowed. Revisions were the biggest gap left over from launch. They’re not anymore.

If you’ve been holding off on revisions because setting up ComfyUI felt like too much for one feature, the gallery button is the easiest way to try it now. I’m curious whether the terrain generator’s two-terrain limit, grass-to-water or floor-to-cliff but not a three-way blend, turns out to matter for anyone’s actual tileset, or whether it’s a non-issue in practice.