Gemini Intelligence is rolling out to more devices. See how expanded capabilities across these devices help you do more.
Gemini Intelligence is rolling out to more devices. See how expanded capabilities across these devices help you do more.
This is a major update that includes many performance improvements, quality of life fixes, 8 new effects, a rewritten layer rendering engine, and a completely new and modernized FileType plugin system. Much of the work has gone into preparing the app for the features and functionality that will be coming in the big 6.0 version that will be coming later (starting with new blend modes and layer folders). There are also 8 new effects and experimental support for running on Wine.
New FileType Plugin System
The original FileType plugin system dates back to 2005 with the v2.5 release. It has withstood the test of time in the sense that it still works and has provided a lot of value for a lot of people, but it has also aged poorly in ways that have prevented progress in other areas of the app. It was written at a time when .NET itself was just 3 years old, and I had no clue that the project’s longevity would stretch so far into the future, nor that so many plugins would be developed.
The old FileType plugin system is tightly coupled with the Document, Layer, and Surface classes which Paint.NET also uses internally for UI and rendering purposes. They only support the 32-bit BGRA32 pixel format and a flat list of bitmap layers. The new FileType system works through interfaces such as IFileTypeDocument<TPixel> and ILayer<TPixel>, along with a rich and strongly-typed imaging framework providing support for a wide variety of pixel formats, pooled bitmap allocation, scaling/interpolation, quantization/dithering, format conversion, color management, and more.
Decoupling the FileType system from the internal classes means that these two systems can now evolve independently, and internal details can be abstracted away or hidden from plugins. The new plugin system has been designed to support graceful versioning, meaning that functionality can be added or changed in the programming interfaces that are provided to plugins while maintaining compatibility for plugins that have already been published. New layer types and topologies (e.g. layer folders) can be added without breaking existing plugins, new blend modes can (and will) be introduced, and bitmap layers can finally be migrated to a tiled storage system.
Note to plugin authors: In general, plugins should provide pixel data in the image file’s original format without converting it to BGRA32. In other words, let Paint.NET handle the conversion, whether you’re supplying pixels as RGBA64, BGR24, or even an HDR format such as RGBA FP16. Paint.NET will figure out the best conversion for pixel format and color profile handling, and when expanded pixel format support is rolled out your plugin can automatically benefit from it. Note that plugins can query at runtime which pixel formats are supported and which are native, in case they do want to do the conversion themselves for whatever reason.
New Plugin SDK available on NuGet
Both the Effects and FileTypes plugin systems have been modernized in recent years, but an easy to reference NuGet package was still missing. Now you can add a reference to the Paint.NET.Plugin.SDK package instead of manually typing out assembly references pointing at your local Paint.NET installation. Note that the classic/legacy plugin systems are not part of the SDK.
New Layer Rendering Engine
The old layer rendering engine has its roots going all the way back to the 1.0 release in 2004. Over the years it has migrated from C# to C for performance reasons, and then back to C# once the language and .NET’s JIT had finally caught up to (and surpassed!) the performance of the native C compiler’s code generation. However, it has no SIMD optimizations, it only has 8 bits of integer precision (“unsigned integer 8”, or “UI8” for short), and the code was very messy and difficult to maintain. Working with many layers can result in incorrect colors or banding artifacts as off-by-1 errors accumulate across multiple layers.
With 5.2, this has been completely rewritten and upgraded to use 32-bits of floating-point precision per channel (FP32). It is fully optimized for AVX2, AVX512, and ARM64 NEON thanks to .NET’s new platform-agnostic intrinsics support. Because FP32 uses a lot more memory bandwidth than UI8, many optimization tricks have been employed so that there is no perceptible performance reduction from previous versions (the old renderer not using any SIMD also helps this comparison). Performance really shines on CPUs with AVX512 support (e.g. AMD Zen 5) even with standard dual channel memory.
A driving factor behind this change was to prepare for future versions of Paint.NET that will expand pixel format support beyond BGRA32. In order to do this in a sane and maintainable manner, having a canonical pixel format became important so that each rendering kernel only needs to be written once. All of the rendering kernels can now operate exclusively on FP32 data, with high-performance format conversion and color transform kernels at the beginning and end of the rendering pipeline. This will make it much easier to add application-level support for high bit-depth formats like RGBA64, and HDR formats like RGBA FP16. The layer rendering engine already supports it, the rest of the app just needs to catch up.
HDR Tone Mapping Support
There are several standard file formats with support for HDR, including PNG, JPEG XL, AVIF, HEIC, and even JPEG XR. Previous versions of Paint.NET could load these images, but would not take into account the extended dynamic range — anything about 1.0 would be clamped, usually resulting in blown out colors. Sometimes the color space was not handled correctly either, resulting in other problems.
Paint.NET now has support for HDR metadata with the new FileType plugin system, and will apply HDR-to-SDR tone mapping as part of the loading process. Future versions will have native HDR support, at which point the automatic SDR tone mapping step will be removed.
We can compare the results of Paint.NET v5.1.2 versus v5.2 with a screenshot from Cyberpunk 2077, which was taken with the help of SpecialK. This is how the HDR AVIF image file looks after being opened in each version of Paint.NET:
Paint.NET v5.1.2 (no tone mapping)
Paint.NET v5.2 (tone mapped to SDR)
Nearest Neighbor (Antialiased)
Available with the Move Pixels tool, this is similar to what some retro game emulators call “sharp bilinear.” It first uses Nearest Neighbor to upscale to the ceiling of the requested scaling factor (e.g. from 100% to 700% instead of from 100% to 632%), and then uses bilinear to downscale to the target scaling factor (700% -> 632%). This retains the blocky/pixelated look of Nearest Neighbor, but with the added effect of antialiased edges. This works for both scaling and rotation.
New Effects
This release adds 8 new effects. These fill in the Artistic submenu, add some new dithering capabilities, two new distortion effects, and finally support for high-quality halftoning.
Examples of each new effect:
Original
Linocut
Mosaic
Pointilism
Stained Glass
Ordered Dither
Spherize
Waves
Halftone
Experimental Wine Support
NOTE: This is not for the faint of heart! It is experimental and targeted towards early adopters who aren’t afraid of missing functionality, performance issues, crashes, and wrestling with dependencies. Calling it “pre-alpha” would be generous.
I’ve recently made major progress getting Paint.NET working on top of Wine, which means Paint.NET can now finally run on Linux and Mac. This is available as a separate package that you can download from a dedicated GitHub repository with its own Releases page and Issues tracker. Updates will be independent(-ish) of the main Windows packages, at least for the foreseeable future. Each new Windows release will be accompanied by a corresponding Wine release so that it doesn’t fall behind in functionality. I do not know when (or if) this will reach a stable and performant level of quality; I suspect that Wine will end up being a stepping stone towards something else, but we’ll see what happens.
What’s coming in 6.0?
The next big update will introduce a new .PDN file format that will finally remove the last barrier to adding new features to the document and layering systems. High bit-depth pixel formats, new blend modes, and layer folders are planned to be the first to take advantage of this. Later on, features such as adjustment layers, text layers, and HDR are also planned (to name just a few).
Change Log
Changes since 5.1.12:
Get the Update
There are a few different releases of Paint.NET:
Settings -> Updates -> Check Now.
The Nvidia CEO’s admission of an affair with a woman US officials believe is a Chinese spy raises big questions about chip export policy, congressional scrutiny, and the AI build-out. NLW breaks down the New York Times reporting, the board investigation, the market whiplash, and the fight over China trade policy. In the headlines: falling Anthropic and OpenAI valuations, Microsoft ending an Oracle compute deal, and Google taking over a stalled Crusoe data center.
The AI Daily Brief helps you understand the most important news and discussions in AI.
Subscribe to the podcast version of The AI Daily Brief wherever you listen: https://pod.link/1680633614
Get it ad free at http://patreon.com/aidailybrief
Learn more about the show https://aidailybrief.ai/
About the show
Sponsored by LongLink: Open-source platform for building and running custom business applications with Python and FastAPI Connect with the hosts
Calvin #1: PyPI's redesigned project pages now warn when provenance changes
Michael #2: gilguard catches the import that turns the GIL back on
gilguard catches a nasty free-threading surprise: importing a C extension without declared free-threading support can turn the GIL back on for the rest of the process. Import gilguard first and it raises a detailed error naming the extension, distribution/version, import chain, and the line of your code responsible.
Calvin #3: pip 26.3: pylock extras, and pip says plainly that untrusted wheels aren't safe
.pth startup hook at Pradyun Gedam's workplace that registers an atexit handler to report interpreter usage metrics over HTTP (https://github.com/pypa/pip/issues/13842#issuecomment-4613463933), plus warnings involving lark_oapi and rich._emoji_codes.pip._internal.commands.install._EAGER_IMPORTS. Pradyun objected that this requires importing from pip._internal, that importing pip's install command is expensive (about 689 ms with no .pyc files and a cold filesystem cache), and that pip isn't necessarily installed in every environment. Shaw's reply: it "just moves where the import cost is," and turning the warning into an error is "crucial."-r pylock.toml[extra1,extra2] for extras, --group pylock.toml:docs for non-default groups, --no-binary with pylock files, and pip refuses to follow an HTTP redirect to a file: URL.Michael #4: All developer tools
HeyUtils is a collection of 306 free developer utilities in 41 categories, with no account or installation required. The full catalog covers data conversion, APIs, networking, DevOps, frontend work and binary protocols. Python developers get model generation and packaging helpers alongside the everyday formatters and decoders worth bookmarking.
Extras
Calvin:
Joke: No papa
In this episode, Andrea Griffiths sits down with Patrick Nikoletich to unpack the Microsoft Copilot harness. Discover how teams are using the harness for non-coding scenarios, autonomous software factories, and customizing the harness for custom agents. Patrick demos a Dockerized agent worker pool, explains credential-safe inference gateways, and shows how the Agent Host Protocol (AHP) tunnels CLI sessions into isolated containers. Explore what is coming in Copilot harness 2.0, from a Rust rewrite to direct Azure tunneling.
Links mentioned in the episode:
Microsoft Copilot harness: https://gh.io/harness
Microsoft Copilot SDK: https://aka.ms/copilot-harness/sdk/repo
Patrick's demo (harness builder + secure Aspire agent service): https://github.com/patniko/copilot-sdk-aspire
Agent Host Protocol (AHP): https://github.com/microsoft/agent-host-protocol
Local sandbox for agents: https://gh.io/local-sandbox
Copilot SDK workshop: https://github.com/github/copilot-sdk-workshop
#MicrosoftCopilotHarness #AIAgents #GitHub
— CHAPTERS —
00:00 Introduction
01:05 From coding agents and personal assistants to fully autonomous agents
02:55 Designing a secure runtime for flexible agent deployments
04:52 Customizing the harness for three different use cases
08:11 Dockerized worker pools and security architecture
10:07 Agent Host Protocol and CLI tunnels
12:20 Direct Azure tunneling and open source access
13:27 What is coming in Copilot Harness 2.0
Stay up-to-date on all things GitHub by connecting with us:
YouTube: https://gh.io/subgithub
Blog: https://github.blog
X: https://twitter.com/github
LinkedIn: https://linkedin.com/company/github
Insider newsletter: https://resources.github.com/newsletter/
Instagram: https://www.instagram.com/github
TikTok: https://www.tiktok.com/@github
About GitHub
It’s where over 180 million developers create, share, and ship the best code possible. It’s a place for anyone, from anywhere, to build anything—it’s where the world builds software. https://github.com
Uno Platform Studio provides the Workbench where Developers and AI Agents create, collaborate, validate, and ship .NET applications together.
Learn more:
Uno Platform: https://platform.uno/
Uno Platform Studio: https://platform.uno/studio
Uno Platform Blogs: https://platform.uno/blog/
Uno Platform Docs: https://platform.uno/docs/articles/intro.html
Uno Platform Discord: https://discord.com/invite/XjsmQHdKfq