PyDPainter: a pixel art program written in Python, in the Deluxe Paint tradition

Deluxe Paint's interface, rebuilt a generation later

PyDPainter, pronounced Pied Painter, after the Pied Piper, is an attempt to create a usable pixel art program for modern computers in Python using PyGame.

The lineage is stated in the README, and it is specific rather than nostalgic. The original inspiration came from the Commodore Amiga version of Deluxe Paint, released by Electronic Arts in 1985. Back then, Deluxe Paint helped define the user interface of a paint program, with tool bars, menus, and the novel use of the left and right mouse buttons for painting and erasing. After pixel art gave way to photo-realism and high resolution 24 bit color, Deluxe Paint was largely forgotten for artistic work.

The argument for reviving it is a cycle argument, and it is the kind of claim worth taking seriously. With the resurgence of all things retro, low-resolution pixel art and limited color palettes have become popular again, and the README's observation is that many tools for this medium are either too complicated or too crude. The project's stated aim is to bring back an old but reliable tool and enhance it with some features to help it coexist in the modern world.

So the audience is pixel artists and people returning to pixel art, and the design brief is the Amiga one. The homepage is pydpainter.org, and the code is GPLv3, with the copyright held by Mark Riale for 2019 to 2026.

One detail tells you how seriously the compatibility goal is taken. The feature list includes Deluxe Paint III compatible, and the project maintains a wiki page listing the differences from Deluxe Paint, which is the right way to make a claim like that checkable.

Two mouse buttons, symmetry modes and 256 undo levels

The feature list is the quickest way to see what the modern enhancements are.

The basics: it runs on Windows, Mac and Linux, it is open source under GPLv3, and it has an easy-to-use user interface with tooltips. The file formats supported are IFF, ANIM, GIF, BMP, PNG and more. There is color cycling, animation, color gradient fills, and a complete set of paint tools.

The two features that go furthest beyond the 1985 original are the painting modes and the symmetry tools. Painting modes include smear, blend, smooth and more, which are the operations you need when you want to soften or merge pixels rather than place them exactly. Symmetry offers mirror, tile and cyclic, which is a set of operations that would be tedious to do by hand and that a lot of modern pixel artists consider essential.

And there are 256 levels of undo. For a program where an accidental drag can ruin a section of a sprite, a deep undo stack is a feature that decides whether the tool feels usable or not.

The mouse button idiom is worth restating, because it explains a good deal of the interface. In the original, the left button painted and the right button erased, which is now a convention in image editors. PyDPainter inherits it, and the tooltips and complete set of paint tools are the modern part layered on top of that older interaction model.

IFF and ANIM are the formats that matter for compatibility

The file format list, IFF, ANIM, GIF, BMP, PNG and more, tells you two different stories depending on which direction you are moving.

PNG and BMP are the current formats, and they need no explanation. IFF and ANIM are the interesting ones, because they are the formats the Amiga world used, and being able to open and save them is what makes this a Deluxe Paint successor rather than just another pixel editor. ANIM in particular carries animation, so the combination of the ANIM format and the animation feature is what lets a sprite move in a way that a still image format cannot.

Color cycling is the other piece of that lineage. Cycling a palette through a fixed set of colors is how the Amiga demos and games produced the water and fire effects that people remember, and it is a technique that depends on a limited palette, which is exactly the constraint that pixel art imposes and that modern editors with 24 bit color do not offer.

So the two features, color cycling and ANIM support, exist for the same reason: they are the parts of the old medium that cannot be reproduced by opening a PNG in a general purpose editor.

The project documents its own differences from the original in a wiki page titled Differences from Deluxe Paint, and the linked RoadMap page shows current progress. Between the two, you can tell what has been ported, what has been added, and what is still planned.

Binaries for users, a requirements file for developers

For most people the install is a download. The README links a Download Latest Release page on pydpainter.org, and the feature list's first line is that it runs on Windows, Mac and Linux, so the released artefacts cover all three.

For anyone running from source, the repository carries the pieces. The dependencies are pinned in requirements.txt:

pygame-ce==2.5.2
numpy==2.2.2

Two dependencies, both pinned to an exact version, which is the right call for a desktop application where a different PyGame build can change behaviour. The use of pygame-ce rather than the original pygame package is worth noticing, since it is the community-maintained fork.

The repository also holds install_pygame.bat, a Windows batch file for installing the dependency, and installing.txt as the written instructions. The main program is PyDPainter.py, and there are two packaging paths. PyDPainter.spec is a PyInstaller spec file, and compile_nuitka3 is a script for the Nuitka compiler, so the project can be frozen either way.

For Linux integration there are the two files you would expect for a desktop application: org.pydpainter.PyDPainter.desktop and org.pydpainter.PyDPainter.metainfo.xml, which is what lets the program appear in the system application menu with a proper name and description rather than as an anonymous Python script.

The repository layout tells you how the program is built

A single file application with a directory of support modules is the shape of the tree, and the directory names are informative.

PyDPainter.py sits at the root next to the packaging files, and get_python_path.py is a small helper that locates the Python interpreter, which is the kind of script that exists because a frozen build and a source run need different paths. libs/ holds the library code, and data/ holds the data the program ships with.

Two directories are more specific. gif2numpy/ suggests a converter between GIF frames and NumPy arrays, which is consistent with a program that both reads animated images and uses NumPy for pixel manipulation. And iff_pics/ suggests the sample or preview images in the IFF format, which would be the artwork that ships as a demonstration of the format support.

The rest is community facing. logo/ holds the logo, docs/ holds the documentation with a Table of Contents at docs/TOC.md and an External Links page at docs/links.md, and .github/ holds the repository configuration.

For someone deciding whether to depend on the source, this is a readable structure with no hidden build system. A single entry point script, a flat library directory and pinned dependencies mean you can read the code without first understanding a build pipeline.

Videos, a road map and a documentation table of contents

The README does the thing that good application READMEs do, which is to point you at the documentation that actually explains the program.

The documentation is a table of contents at docs/TOC.md, with an external links document at docs/links.md for anything the project points outside itself, and the wiki carries both a RoadMap page for current progress and the Differences from Deluxe Paint page.

Then there is video. The README lists a Quick PyDPainter Demo, trailers for 2.0, 2.1.0 and 2.2.0, and a PyDPainter tutorial playlist. For a program whose selling point is a user interface inherited from a 1985 application, video is the efficient way to show what the two mouse buttons do, which a static screenshot cannot.

The project also runs several community channels. There is a Ko-fi donation page, a Facebook group, and a Mastodon account at @[email protected]. The presence of a donation page next to the GPLv3 licence is a familiar combination in this part of the open source world, where the code is free and the maintainer is not.

A small detail that says something about the project's care: the copyright line reads PyDPainter Copyright (C) 2019-2026 Mark Riale, and the licence is GPLv3 or later, with the details in the LICENSE file. The year range is kept current, which is a low-effort signal that the project is not abandoned.

Sparse releases, active repository

The release record is short and irregular. Release 2.2.0-beta.1 is dated 2025-06-01, Release 2.2.0 on 2025-06-14, and Release 2.2.1 on 2026-01-27. The last push to the repository was on 2026-10-13.

Read that pattern carefully. The beta and the final of 2.2.0 arrived a fortnight apart in June 2025, which is a quick turnaround for a release candidate. Then 2.2.1 came in January 2026, and the branch has been moving since with no new tag in sight.

That is the profile of a mature, small, single maintainer project. The feature set has been stable for a while, the work between releases is maintenance and gradual improvement, and there is no release train to wait for. For a user, that means the download page is the source of truth and the newest binary is what you get, with no expectation of a rapid stream of new versions.

For a developer considering a dependency, the practical point is the same one the licence makes. This is GPLv3 or later, so if you want to ship PyDPainter inside a closed product, that is a different conversation from contributing an improvement to it. The project is a desktop application first and foremost, and the code is meant to be run, studied and modified, not vendored into a service.

The pragmatic path for most people is the released binary, with the source and the wiki available when a feature is missing or a file will not open.

Editorial conclusion

PyDPainter suits pixel artists who want a dedicated low-resolution canvas with a fixed palette workflow, a two-button tool idiom and animation support, and it suits anyone who needs to open or save the legacy IFF and ANIM formats that Deluxe Paint produced. It does not suit a general illustration workflow, since a limited palette and pixel-locked tools are the point rather than a limitation to work around, and it does not suit a team that needs a maintained release train, because the tagged releases are sparse and the 2.2.0 beta shipped more than a year before the final. Check three things before you adopt it: that the released binary matches your platform, that the documentation table of contents covers the features you need, and that the file formats you exchange are among IFF, ANIM, GIF, BMP and PNG. The last push to the repository was on 2026-10-13 and the newest tagged release is 2.2.1 from 2026-01-27.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. mriale/PyDPainter on GitHub
3. Project website
4. README
5. Releases