Arknights Pixel Autofill: turning photos into 24x24 Arknights pixel art and painting them in-game

The 24x24 colouring job this tool automates

Arknights' pixel-art editor gives you a 24x24 grid and a 40-colour palette. Filling one picture by hand means up to 576 individual colour selections and clicks, and doing it twice means doing it twice. This project attacks both halves of that job: it converts a source image into a 24x24 grid quantised to the game's 40 colours, and then it clicks the game for you.

The audience is narrow and the README is honest about it. The tool is Windows-only, it asks for administrator rights at launch (the README says cancelling the UAC prompt makes it exit), and it exists for people who play on the PC client or on an emulator. If you only want to design pixel art and export a PNG, the conversion half is useful on its own; the automation half is useless without a running game window. That split matters when you evaluate it, because the two halves have very different failure modes.

How the converter quantises an image to the 40-colour palette

The pipeline is visible in the module layout: `palette`, `image_processing`, `vision`, `layout` and `automation` are separate modules, and the README says image processing was split out specifically so resampling, colour matching, structure enhancement and direct bitmap import could be tested separately.

Conversion runs in stages. Resampling supports Lanczos (the default), BOX, Bicubic and Nearest, and a "sampling smoothness ratio" slider blends continuously between Nearest at 0% and the selected algorithm at 100%. Colour matching then compares each pixel against the 40-colour palette using either classic RGB distance or OKLab, with a second slider blending the two distance models. Finally, two optional stages: "reduce transition colours" keeps at most 16 frequent colours and disables dithering, and "structure enhancement / shadow removal" compresses large-scale lighting variation before the downscale. The README states the default for structure enhancement is 0%, which preserves the v1.3.0 processing path.

The README is unusually direct about the trade-off here: it says there is no fixed conclusion about which matching algorithm is better for all material, and that you should judge by contour, skin tone and subject legibility in the ungridded thumbnail. That is a fair statement, and it also means the tool expects you to make aesthetic decisions, not just press a button.

Installing and running a first conversion from source

There is no package on PyPI. The README points to GitHub Releases for the prebuilt `Arknights-Pixel-Autofill-v1.4.0.exe`, and to a Quark netdisk link posted in the comments of the author's Bilibili release page. Running from source requires Windows, Python 3.10 or higher, and an administrator PowerShell session.

The README gives this exact sequence, which clones the repository, creates a virtual environment, installs dependencies and starts the Qt entry point:

git clone https://github.com/JayJokerr/arknights-pixel-autofill.git
cd arknights-pixel-autofill
py -m venv .venv
.\.venv\Scripts\Activate.ps1
pip install -r requirements.txt
python arknights_pixel_qt.py

According to requirements.txt, the dependency set is small: Pillow 10.0 or newer, pywin32 306 or newer, and PySide6 pinned exactly at 6.8.3. The pin is worth noticing. PySide6 is the whole interface in v1.4.0, so a dependency resolver that moves that version is the first thing to suspect if the window misbehaves.

For a first real use, the README's own order is: click 选择图片 to import a PNG, JPG, WEBP, BMP or GIF, use the 1:1 crop window if needed, start from the Lanczos plus classic RGB default, then compare against BOX, Nearest, OKLab or the transition-colour reduction in the thumbnail. If you already have a finished 24x24 PNG, the 24x24位图 import path skips cropping and resampling entirely: each source pixel maps to one cell, and pixels already inside the 40-colour palette are kept as they are.

Dynamic canvas and palette recognition replaces fixed coordinates

The headline change in v1.4.0 is that the tool no longer carries hardcoded coordinate offsets for a resolution or an emulator brand. Instead it enumerates windows, asks you to pick one from a dropdown that shows title, client size and PID, and then searches for the actual rendering client area by process, parent-child or owner relationships.

Once it has a candidate surface, two detectors run together and their scores are combined. One looks for a near-square outer frame and divides it strictly into 24x24. The other fits 25 evenly spaced horizontal and vertical grid lines and checks spacing, ordering and residual error. Navigator thumbnails and window borders are excluded using canvas aspect ratio, squareness, palette position and expected region. Baseline coordinates are only a search prior; the click target comes from the centre of the detected adjacent grid lines.

On the palette side it identifies 4 columns, 6 visible rows, the colour-block centres and the current visible colour-number range, then compares block medians against the full 40-colour order to decide whether the palette is at the top or scrolled. If a needed colour is still not visible it stops rather than picking from the wrong row. The README states plainly that if canvas and palette are not both recognised, the program stops and does not fall back to guessed proportional coordinates. That is the right design choice, and it is also why the tool fails visibly instead of quietly painting garbage.

Where it breaks: emulator scaling, unsigned binaries and focus rules

The most concrete limitation is documented as a warning: if a MuMu window is manually shrunk too small, the internal rendering may scale differently and the program cannot reliably identify the canvas or palette. The recommended debugging baseline is a 1280x720 client area at 100% game UI scaling, with the game window fully on one monitor and the canvas and palette unobstructed. The tested matrix covers 1280x720, 1920x1080, 2560x1440 and 3840x2160, game UI scaling from 90% to 100%, and MuMu at three resolutions. Phones, cloud gaming, remote desktop, unusual aspect ratios and untested emulators are explicitly outside that range.

The second limitation is distribution. The README states the release is not signed with a commercial code-signing certificate, so Windows SmartScreen may show a reputation prompt for a low-download binary, and it asks you to verify the file name and SHA-256 before running. That is a real friction point for anyone deploying this on a managed machine.

Third, the automation is strict about focus and geometry. During filling, the cursor is confined to the selected client area, each target coordinate is clamped to a safe boundary, and the position and resolution of the rendering window are re-checked before every colour pick and click. If the window moves, resizes or is rebuilt, filling stops. Foreground focus must belong to the selected window or the same process, and if focus cannot be confirmed the program refuses to start capturing and clicking. The README also notes the tool and the game must run at the same privilege level, and that F8 is the emergency stop.

How it compares with writing your own Pillow script

The obvious alternative is a short Python script: load the image with Pillow, resize to 24x24, and map each pixel to the nearest colour in a hardcoded list of the 40 game colours. That approach is fully within your control and needs no administrator rights, no window enumeration and no PySide6.

The difference in approach is where the work sits. A hand-written script gives you nearest-neighbour or Lanczos resizing and one distance metric, usually Euclidean RGB, and nothing else. This project adds the parts that are tedious to write: an OKLab distance path, a continuous blend between Nearest and the chosen resampler, the 16-colour transition reduction with dithering disabled, and the structure enhancement stage aimed at photographic shadows. It also adds the half a script cannot do at all, which is finding the game canvas on screen and clicking it.

If your source material is already pixel art with clean edges, the extra processing stages are mostly noise and a plain script is closer to what you want. If your source is a photograph or a shaded illustration, the resampling and colour-matching sliders are the reason to use this instead. The README's own guidance supports that reading: it suggests keeping structure enhancement at 0% for existing pixel material and trying 30% to 65% for shadowed photographs.

Licence, maintenance and what an upgrade costs you

The repository is MIT licensed, which permits commercial and private use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence with no copyleft obligation. It says nothing about the game: the project automates input into Arknights, and the licence covers the code, not your relationship with the game's terms of service. Nothing in the README addresses that question either way.

The last push to the default branch was on 2026-08-19, and the repository is not archived. Three releases landed in August 2026: v1.2.0 on 2026-08-09, v1.3.0 on 2026-08-10 and v1.4.0 on 2026-08-12. That cadence suggests active work, but the README does not document a rollback path, and the release notes file in the repository root is specific to v1.4.0.

Upgrade cost is shaped by two things. The v1.3.0 to v1.4.0 jump moved the interface from Tk to PySide6, added a window-selection dropdown in place of a title-keyword field, and replaced fixed offsets with dynamic detection, so anyone on v1.3.0 is changing automation strategy, not just picking up fixes. And because the executable is unsigned, every new version re-triggers the SmartScreen and checksum verification step. The repository ships a SHA256SUMS.txt alongside the release artifacts, which is the file to compare against.

Editorial conclusion

Adopt it if you play on the PC client (official or Bilibili server) or on MuMu at 1280x720 with 100% game UI scaling, and you are comfortable running an unsigned executable as administrator. Skip it if you play on a phone, through cloud gaming or remote desktop, or on an emulator the README does not list as tested: the README states those are outside the tested range and that the tool stops rather than guessing when it cannot identify the canvas. Before running anything, verify the SHA-256 value 06929354526EF9F36EA97A63222848A21321CEED30C616D4F62ED069E88FE6D5 against the downloaded Arknights-Pixel-Autofill-v1.4.0.exe, and check that requirements.txt pins PySide6==6.8.3 if you run from source.

Frequently asked questions

Official sources

1. Issues
2. JayJokerr/arknights-pixel-autofill on GitHub
3. License: MIT
4. README
5. Releases