Repository navigation
FAQ
No issues had been filed when this page was last updated (2026-10-26). These questions come from the skills, the README and what the wiki's run showed.
Run snap alone first. A render with a grid gives a scale above 1 and a native size close to what you expected; a painted image gives scale 1 and no coherence field (Making pixel art). The skills treat painted sprites as their own kind of art: do not snap or quantise them. The gates will not warn you: a painted gradient reduced to 8 colours passed every make gate (Gates).
Since 0.8.0 snap needs enough colour edges to tell a grid from chance: at least 8 edge positions, and a coherence of at least 2.8 divided by their square root. A smooth render, a JPEG above all, has only a few strong edges, and 0.7.0 lined some of them up at scale 57 into a 13x13 mush (Making pixel art). If the image really is pixel art at a known size, give --scale (and --offset), or "snap": {"scale": S} in a recipe.
Noise. Each block's inner 60% has several near colours, so no block is one colour, and each still takes its most common colour. The mushroom render read 0.0 at the right scale and offset; the same sprite upscaled cleanly read 1.0. The make skill's hint about a wrong offset applies to a clean upscale.
Yes. A 5.5x upscale read as 5.498, with the right 20x20 native size (Making pixel art). When the scale comes out at half or double the true one, give --scale (render width over native width).
The background step runs by default and clears every border-connected pixel near the most common border colour. On art with no flat ground it eats into the picture: 4,030 of 12,288 pixels of the painted gradient. Put "background": "none" in the recipe.
No. Without it the aw_pixel gate says skipped and everything else runs. With it, use pixelwright 0.6.1 and artwright 0.4.1 or later together. The current archive run used pixelwright 0.8.4 with artwright 0.7.0. With pixelwright 0.6.0 or artwright 0.4.0, sprites with a dark outline against transparency failed the verdict (Gates).
Median cut made 8 and merged two that look alike. Ask for one or two more.
No. It has no network code apart from review, which serves on 127.0.0.1 only. Palettes from Lospec or elsewhere are files you download yourself; only PICO-8 ships, because it is CC0 and other palettes carry their own licences.
pxw.py never calls it. The skills name PixelLab as a paid route: for a new sprite before make, and as the fallback for motion code cannot fake (a dome opening, an arm unfolding). They say to ask the person first, naming what it is for and what it costs, and to read the key from PIXELLAB_API_KEY, never from a file. Its frames come back through the external effect, which takes only the region and snaps it to the still's palette. Not run for this wiki.
In 0.6.0 and 0.6.1 a missing or unreadable input file in most commands ended in Python's traceback on stderr, exit 1. Since 0.6.2 it prints "ok": false with the error as JSON, still exit 1 (Commands). Check the path first.
Pillow 11.3.0, the newest that installs on 3.9, warns about an argument pxw.py passes when it writes images. The output is the same; newer Pillow (13.0.0 included) does not warn (Getting started).
The wiki's run printed the same reports on Windows and Linux and on Python 3.9 and 3.14. The differences were version numbers, Python 3.9's warnings, and the wording of some error messages from the operating system and from Python's argument parser. Two runs of the same brief gave byte-identical sheets.
The make skill names them as other fixers: use one when the person already has it, compare the results with aw.py pixel, and keep whichever scores cleaner. pixelwright has its own grid detection so that it works without artwright, and calls artwright's checks rather than copying them. No comparison was run for this wiki.
This wiki describes pixelwright 0.8.4 and was last updated on 2026-10-26. The plugin is MIT licensed. Report problems in the issues. On GitHub: release v0.8.4.
Using it
The releases
Contributing
Elsewhere