Paint.NET is jointly developed at Washington State University with additional help from Microsoft, and is meant to be a free replacement for the MS Paint software that comes with all Windows operating systems.Paint.NET is a photo editor and manipulation software.

Download notes: Alternatively you can download the latest stable version of this software.

The programming language used to create Paint.NET is C#, with GDI+ extensions.

Paint.NET has many of the powerful features that expensive commercial applications have, including the ability to use layers.

This is the second semester that Paint.NET has been a project at Washington State University, and we have the goal of adding as much functionality as expensive commercial applications provide, but of course, for free.

In the spirit of all this freedom, we welcome any suggestions, as well as provide the source code free of charge for anyone who wishes to tinker with it.

What's New

There's quite a bit that has changed since the last alpha release (build 8930). I didn't plan on a month-and-a-half long gap between builds, and I was actually hoping to be close to the final/stable release by now, but everything I've been learning about color management and Windows' built-in support for it led me to a few important course corrections. I also implemented some rather dramatic memory usage and performance improvements.

Here's a quick summary of what's new/changed for the beta when compared to the alpha:

  • Massive reductions in memory usage when working with multiple images
  • Greatly improved canvas framerate for lower-tier and integrated GPUs (e.g. Intel UHD/Iris/Xe, AMD Radeon Mobile)
  • Color management for the display now handled by Windows via Advanced Color and Automatic Color Management

Massively Reduced Memory Usage

I've been wanting to make this optimization for awhile, but it was a very technically challenging problem and I was never able to make enough progress on it (while also keeping the app stable and reliable, mind you).

Thankfully some new pieces of the puzzle recently fell into place which turned this into a very easy problem to solve. I'm happy to report that GPU memory usage when working with multiple images has been massively reduced. See below in the tiny print for the technical details.

In addition, earlier in 5.1's development I implemented an optimization that greatly reduced CPU memory usage by up to half. This was done by moving canvas tiles to the GPU instead of copying them. Tiles can be easily recreated, so why keep them around on the CPU? The only real downside is that toggling certain settings, namely "Enable hardware acceleration" and "Windows Advanced Color," will result in a brief flickering of the canvas and other UI elements.

The savings are really quite dramatic and should smooth things out a lot for many folks. Let's explore this with some data from 2 scenarios that I tested. For both of these tests I started Paint.NET, maximized the window on my 4K display, and then opened a series of images. Memory usage figures were taken from Task Manager.

In the first test, I opened up 50 images that are 6 MP (megapixels) in size (3000 x 2000 pixels). In PDN 5.0.13, the memory usage was 2,527,960 KB on the CPU and 5,818,172 KB on the GPU (about 2.5 GB and 5.8 GB respectively). In the 5.1 Beta, it's down to 1,402,148 KB on the CPU and 2,427,332 KB on the GPU (about 1.40 GB and 2.43 GB respectively). So it's about a 50% reduction overall.

This one is more contrived, at least in my opinion, but it shows how much better things are in a more extreme scenario. For this I opened 200 very small images between 16x16 and 64x64 pixels (various icons from the PDN UI). In PDN 5.0.13, the memory usage was 356,772 KB on the CPU and 12,431,560 KB on the GPU (which is about 12.43 gigabytes). In the 5.1 Beta the memory usage on the CPU was down a little bit at 335,044 KB while the GPU memory usage was reduced by over 97% to just 281,188 KB.

So depending on how many images you open, and how big they are, you could easily see PDN using 50% less memory on both the CPU and the GPU. Things will be faster and more stable as a result. Enjoy.

Greatly Improved Canvas Framerate

I'll admit, I was getting a little worried about PDN 5.1's performance during the alpha. It performed perfectly fine on my desktop PC, but it has a top-end CPU and GPU so that's no accomplishment. On my laptops and other test systems, which mostly have Intel iGPUs, I was not able to get anywhere close to the level of PDN 5.0's performance. The canvas still ran at 30+ FPS, so it was still well within what they call "interaction class" performance, but it lacked the refined smoothness that it really ought to have.

After some deep performance investigations and completely rethinking and redoing how the canvas is rendered, I'm happy to report that this is completely fixed! Framerates on typical integrated GPUs (which power almost all laptops) are now solidly in the 60+ FPS range. I have also been able to improve performance for when hardware acceleration is not enabled, which should help on systems with very old GPUs that don't support DirectX 11, or when running the app in a virtual machine or other shared environment where a GPU is not available.

The ironic thing is that this performance improvement was mostly made by reducing the involvement of the GPU. Paint.NET's color management is now mostly performed on the CPU in background as part of layer composition and mipmap production. Completed tiles are now sent to the GPU in a "presentation ready" format (FP16, scRGB color space). Before, tiles were sent over using the linearized color space from the image, and this required additional color space transforms on the GPU while rendering the canvas. Those are now all gone, and in their place are a nice framerate boost and a reduction in power consumption. Scrolling and zooming are much better now.

Display Color Management now handled by Windows

In the alpha there was a checkbox in Settings -> Color Management that was labeled "Use the display's color profile." To make use of this you had to be using an SDR display (which most are these days), and you needed a color profile for your display, and you needed to have installed that color profile using the super confusing Color Management control panel.

I left this setting disabled by default because I didn't think a lot of people would be able to take advantage of it properly (not without a lot of work anyway), and enabling it by default would've resulted in many people thinking that color in Paint.NET was now "broken". In addition, the code for handling all of this was complex and fragile, and would have been difficult and expensive to maintain going forward.

The other checkbox in Settings -> Color Management, "Windows Advanced Color," applied to displays configured for High Dynamic Range (HDR) or Wide Color Gamut (WCG) mode. In this mode, Windows manages color automatically with respect to the display by utilizing the color space information provided via EDID. You don't need to install a color profile or deal with the old school Windows Color Management control panel.

The "Use the display's color profile" setting is now gone, leaving only "Windows Advanced Color" (enabled by default). This means that color management for the display in Paint.NET is handled exclusively by Windows, and is only dependent on having configured the display for either High Dynamic Range (HDR) or Wide Color Gamut (WCG) mode. I expect HDR and/or WCG to gradually become the mainstream configuration, leaving SDR as a historical relic (eventually), and so it made no sense to me to keep the complicated code for "Use the display's color profile" given the projected cost of maintaining it. I'd have to rip it out eventually anyway, so why even ship it in the first place?

Many people know what HDR is, and in Windows it has a reputation for being finnicky and buggy. Complaints about "washed out colors" are common when enabling HDR, and this is actually a complicated and difficult color calibration problem. HDR mode works very well ... if your PC manufacturer calibrates and configures things correctly, or if you spend several hours fiddling with the color settings on your display. My Lenovo P16 laptop works great in this mode, but every other system and display I have has a lot of difficulty with it.

WCG has not gotten a lot of attention (yet?), and does not seem to have the problems that HDR mode does. WCG is actually a new variant of SDR mode introduced in Windows 11 (you can also use it on HDR displays). In WCG mode, Windows will use 10-bit output (or 8-bit with dithering) and enable Automatic Color Management just like it does in HDR mode.

Starting with Windows 11 v24H2, most SDR displays can use WCG mode as long as the GPU is modern enough (see here for requirements). You can think of WCG in two ways: it's either HDR without the extended brightness range and bugginess, or it's like SDR mode but with high bit-depth output, Automatic Color Management, and access to the display's full color gamut (its full range of colors) (btw, SDR mode is always limited to 8-bit output, regardless of any settings in the GPU's vendor-specific control panel).

Changes since 5.1 alpha build 8930:

  • Improved: GPU memory usage when working with multiple images has been massively reduced
  • Greatly improved performance (framerate) for the canvas on integrated and lower-tier GPUs
  • Removed: Settings -> Color Management -> "Use the display's color profile." Color management with respect to the display is now handled exclusively by Windows and requires a display configured for High Dynamic Range (HDR) or Wide Color Gamut (WCG).
  • Improved: Windows Advanced Color is now used for the Colors and Layers window, as well as for image thumbnails at the top of the main window. They are no longer limited to sRGB and can display the full range of colors defined by each image's embedded color profile.
  • New: Effects -> Render -> Clouds now has a tab for configuring the colors used for rendering
  • New: Effect plugins are now provided "managed" environmental colors (primary, secondary, palettes). You can use these with IndirectUI by using a ManagedColorProperty (for a color wheel UI), and you can use them to render with Direct2D with the ManagedColor.Get(IDeviceContext) instance method.
  • Changed: the minimum OS requirement is now Windows 10 v21H2 (it used to be Windows 10 v1809)
  • Updated: The bundled AVIF FileType plugin has been updated to version 3.9.1 (thanks @null54!)
  • Updated: The bundled DDS FileType Plus plugin has been updated to version 1.12.9 (thanks @null54!)