paint.net 4.2 beta build 7116 is now available

To get this update, make sure you have "Also check for pre-release (beta) versions" enabled in Settings, and then click on the Check Now button.

image.png

You can also download it directly by heading over to the forum.

Changes since 4.2 beta build 7111:

  • New: Saving in HEIC format is now supported. Windows 10 v1809+ is required, along with installation of HEVC Video Extensions from Device Manufacturer (free) from the Microsoft Store.
  • Improved: If you try to open or save an HEIC and you do not have the Microsoft codec installed, the error message will provide you a link to go get it. (The link is in the "Show Details" section)
  • Fixed: Pasting from some sources (e.g. Google Chrome) should no longer be shifted to the right by 3 pixels, nor have 3 colored pixels at the bottom left, and should also have working alpha/transparency again. This appears to be a bug in Windows 10 v1903 when both CF_DIB and CF_DIBV5 are on the clipboard and in that order (in other words, CF_DIB is higher priority than CF_DIBV5).
  • Fixed: The LowColor File Type plugin should work again. It still has a bug where it may show its own error dialog while you are modifying the properties for saving. This dialog can be ignored and dismissed.
Advertisements

paint.net 4.1.7 alpha (build 7107) is now available

Okay so hopefully this is the last alpha build before I’m able to get a beta out the door (incl. updated translations). Just fixing up a few things that were important enough to fix quickly instead of waiting for the beta.

Head on over to the forum to download it.

NoteGive me a few minutes and this will also be available via the built-in updater.

Changes since build 7104:

  • Improved: TGA images now load about 4x faster (thanks @null54!)
  • Fixed: Clipboard extension methods now available for plugins to use
  • Fixed a crash at startup when loading some FileType plugins
  • Improved: Slightly increased the size of the Settings dialog to reduce the need for scrolling in a few important situations

paint.net 4.1.7 alpha (build 7104) is now available

This should be the final alpha release of 4.1.7. Next up I’ll be integrating translation updates, fixing any last issues, and releasing the final build.

A lot more work went in this build than I was expecting! I decided to take on the work of making sure effect plugins could have good access to the clipboard, which is otherwise a very buggy area to navigate. A lot of other bugs and things were sorted out as well.

To download, head on over to the forum where I’ve posted a direct download link.

Note: I’ll be adding this to the built-in updater shortly. For now, please use the download link at the forum.

Changes since build 7079:

  • New: Keyboard shortcuts for changing the current layer. You can see these in the Layers menu with the "Go to …" commands. Alt+PgUp/PgDown will go to the layer above/below, and Ctrl+Alt+PgUp/PgDown will go to the top/bottom layer.
  • New: PNGs can now be saved as "interlaced"
  • New: Plugins that use IndirectUI can now use a UriProperty with a LinkLabel control (thanks @null54!)
  • New: Effect plugins can now more easily make use of the clipboard via the IClipboardService. It will handle all of the tricky clipboard issues such as threading, native data marshaling, and avoiding security vulnerabilities that exist in the standard WinForms and WPF clipboard APIs.
  • Improved: When using Edit->Copy, a 32-bit BGRA bitmap in the DIBV5 format is now placed onto the clipboard so that other apps can read the alpha channel.
  • Improved: When using Edit->Paste, DIBV5’s are now supported if they have an alpha channel. If they don’t, then the regular DIB loader is used which has some heuristics for detecting an incorrectly defined alpha channel and correcting for it.
  • Improved: When using Edit->Paste, PNG is now the highest priority format. This maximizes the ability to maintain alpha/transparency, but it does mean that images coming from Microsoft Office apps will appear larger than they used to. This is either a bug or a feature of Microsoft Office. For some reason it places PNGs on the clipboard that are 25%+ larger than the DIB/DIBV5 bitmap that it also places on the clipboard (but which don’t have alpha/transparency).
  • Fixed: 8-bit TGA images should now load correctly (thanks @null54 for the fix!)
  • Fixed: Some 32-bit TGA images were showing up as completely transparent due to their use of an obscure alpha channel type (thanks @null54 for the fix!)
  • Fixed: Simple message boxes can now be closed with the ESC key
  • Fixed: Some TIFFs could not be resaved as a JPEG due to having too much metadata (usually from Adobe Photoshop). The metadata is now discarded if necessary.
  • Changed: Blocked the WebP FileType v1.1.0.0 plugin due to instability. An update is already available.
  • Changed: Blocked the ImAgif FileType v0.12.0.1084 plugin due to incompatibility. An update will hopefully soon be available.

Enjoy!

paint.net 4.1.7 alpha build 7079 is now available

I believe I’ve fixed the issues that were preventing some images from being saved (as reported earlier). I also fixed a few things in the Save Configuration dialog that were supposed to make it into alpha build 7077, but didn’t because I incorrectly merged my pull request on GitHub.

The issue with the images that wouldn’t save was that they had UserComment metadata in them (EXIF tag ID #37510). WIC (Windows Imaging Component) handles this in a way that my code wasn’t coping with, so the data didn’t round-trip correctly, and WIC decided to refuse the transaction instead. (And there was another bug: part of my wrapper was returning an error when WIC tried to send an IStream::Write() call with a 0 byte payload … weird, probably a bug in their code, but shouldn’t have broken down on my side.)

To download, head on over to the forum. I’m currently adding this to the auto-updater as well, so in a few minutes you should be able to open up the app and head over to Settings (gear icon at top right of main window) –> Updates, and click on the “Check Now” button (but make sure “Also check for pre-release (beta) versions of paint.net” is enabled!). For Microsoft Store users, you’ll need to install the Classic version to try this build out (I don’t yet have alpha/beta builds working for the Store). It can be installed side-by-side with the Store version and uninstalled when you’re done with it without affecting the Store copy.

Change log:

  • Fixed: Some images could not be saved as JPEG due to mishandling of some metadata
  • Fixed some error handling in the Save Configuration dialog. An error dialog will now pop up to show the exception that occurred in addition to the usual "Preview: (error)" text that has always been shown.
  • Fixed: HEIC/HEIF file extensions are now registered with Windows so that you can double-click on them in Explorer to open them in Paint.NET

Enjoy! :)

Paint.NET 4.0: Brushes and Shapes and stuff

Wow, it’s been awhile since I posted! Let’s see what’s new …

Brushes

The new brush engine is still in its infancy so I don’t have any good screenshots I’m willing to share at this point. It fully supports “softness” which is a staple of every brush-based drawing programs other than Paint.NET (pre-4.0 Smile). I’ve found it a bit tricky to get good performance within the new rendering engine, but I’ve mostly solved how to do it right (it’s a classic performance vs. memory usage trade-off) and just need to write the actual code. The initial 4.0 release will not support custom brush shapes (“stamps”), but it should be fairly straightforward to add them afterward.

Once the brush engine is in place for the paintbrush tool, I will be able to quickly rebuild the eraser, clone stamp, and recolor tools so they can all have the same features and rendering quality.

Pressure Sensitivity?

I just got a Surface Pro, and it’s pretty slick. More importantly, at least for Paint.NET, is that it has a good Wacom-based stylus/pen with pressure sensitivity. I originally dropped pressure sensitivity in v3.5 because that part of the code was getting in the way of some very important improvements to the input system for the brush tools. That in itself wasn’t a good reason for dropping it, but I had no hardware to test with so I could be sure that I wasn’t breaking pressure sensitivity (or worse). Now I’ve finally got some good hardware for this, so 4.0 might support it, at least for Windows 8 and up since it has new APIs that provide this as a first-class input mechanism. From what I’ve looked at, it’s promising, but I’m still not sure if it’ll work the way I need it to. Cross your fingers.

Shapes

I haven’t stalked about the new Shapes tool yet, which is a cornerstone of the new toolset. Instead of having one tool for each shape (rectangle, circle, etc), there is 1 shape tool and you choose your shape from the toolbar:

Once you’ve drawn a shape you’re free to move, rotate, and resize it. You can also change the shape type or adjust everything else about it (colors, brush size, etc) until you’ve committed it to the layer (and of course, “fine grained history” is fully supported). You can resize the shape using the 8 corner handles, you can move it with the "compass" handle that appears to the lower right of the shape, and you can rotate by placing the mouse between the bottom-right resize handle and the move handle. When you do that, a two-sided curvy arrow appears underneath the mouse cursor to let you know you can drag there to do some rotation:

(You can also move by dragging elsewhere, but the compass handle makes it very obvious as to where you can always drag to move it.)

The handle in the center, which I guess I call “the screw”, can be moved around and lets you redefine what a rotation will use as its center point.

This UI for the resizing, moving, and rotating is the same one that the new Move tools use. Consistency for the user + reusability for the developer = good.

Custom shapes will not be supported in 4.0, but are planned for a release soon after that (sorry y’all, gotta prioritize!). All of the shapes stuff is based on a programming model that’s nearly identical to the Geometry system in WPF/Siverlight/XAML, so once you can add your own shapes it’ll be easy to find examples online with some XAML or path markup which you can then use in Paint.NET.

Not Abandoned

Lastly, to all the people who’ve sent e-mails or left comments asking if Paint.NET is still alive: yes! I just haven’t updated the blog in awhile. I also haven’t made much progress in the last few months because I haven’t had as much time for it; the amount of time I was putting into it was burning me out a bit. But yes, it’s still alive! 4.0 is still on the way, it’s just a really large project that takes a lot of time.

How to fix: Diablo 3 “Blizzard Update Agent has stopped working”

I finally succumbed and bought a copy of Diablo 3 today, only to found out that it just doesn’t work:

Argh! No matter what I did, it would always crash. Every single time, over and over and over and over again.

In a last act of desperation before borrowing the DVD from a friend to try and load it that way, I had some Raymond Chen style psychic insight and thought it might be a multithreading bug. You see, I just put together a brand new Dual Xeon E5-2687W system. It is a beast: dual processor, 8 cores each, with HyperThreading. That means Task Manager shows 32 tiny little performance graphs. It makes compiling Paint.NET really fast (lots of C++/CLI these days), and is killer for working on all that multithreaded rendering code.

Anyway, the fix is a bit clumsy but it seems to work (so far! we’ll see if it still works after all the downloading is done):

  1. Download the “Diablo-III-Setup-enUS.exe” as usual, from Blizzard’s website.
  2. Run it, as usual (double click on it).
  3. When you get the UAC prompt, do NOT click Yes (yet).
  4. Instead, open up Task Manager and find the program in the “Processes” tab (Diablo-whatever.exe)
  5. Right click on it and then click on the “Set Affinity…” command.
  6. Make sure only 1 of the CPU’s checkboxes is enabled. If you’re on Windows 7, just click the “<All Processors>” node to uncheck everything, and then click on “CPU 0” to enable it. This will lock the program to just 1 CPU core/thread, minimizing the risk of the hypothesized multithreading bug.
  7. Now you can click on Yes in the UAC prompt… and tada, it should work.

I found some battle.net forum threads where tons of people are having this issue, and it goes on and on for pages and pages without any fix for the poor souls (so to speak).

Once it starts downloading you’ll probably want to do the same thing for “Blizzard Launcher.exe” except that this time you’ll 1) have to click the “Show processes from all users” button (bottom of Task Manager in the Processes tab), and then 2) enable all CPUs instead of having any of them disabled.

Hope this helps anyone else who’s having this frustrating problem.

Update: Once Diablo 3 finished downloading, it still would not start after clicking the Play button. “Diablo III.exe” would pop up in Task Manager, and then silently disappear a few seconds later. According to the Windows Event Viewer, it was crashing. However, I did get it to work, and the trick is to “Set Affinity” on explorer.exe and give it something like 4 of the CPU cores. Since processor affinity is inherited, running Diablo 3 from within Windows Explorer (aka your desktop) now works. Hey Blizzard! Try testing on something more than a dual core Pentium D!

Paint.NET forums moving to a new server

This is just a little note to explain why the forum may not be accessible for a little while. It’s moving to a better server, although it’ll have the same http:// location.

You shouldn’t have to do anything other than be please be patient for the next day or so, and then things should be back to normal once all the new DNS stuff propagates.

Apparently we were put on the wrong server during the last migration, and just recently we’ve been bumping into all of its CPU usage limitations 🙂

Optimizing .PDN Save Times

Every once in awhile you get an idea for an optimization that is so simple and so effective that you wonder why you didn’t think of it much earlier. As a case in point, someone recently posted to the forum that their image was taking a long time to save. It was an image comprised of 20 layers at 1280×720 pixels, and 20 seconds was deemed to be too long. The guy had a brand new AMD Phenom II X4 960T 3.0GHz gizmo with 4 CPU cores, plenty of RAM, and an SSD. It was obviously bottlenecked on the CPU because Task Manager was pegged at 100% while saving.

Please wait forever

The only advice I could give for the latest public release of Paint.NET (v3.5.10) was that if you need it to save quicker, either 1) use fewer layers, or 2) get a faster CPU with more cores. This is very technical advice, and in some circles that works just fine especially if it’s practical and economical, or if you’re dependent on saving time in order to make money (saving 5 minutes every day is often worth $100 to buy more RAM). Using fewer layers isn’t a good solution though, and replacing the CPU usually isn’t very practical either especially if it’s already a brand new upgrade.

It got me thinking though, that Paint.NET can still do better. If you’re working with a lot of layers then chances are that each layer is mostly blank space. Lots of transparent pixels with an RGBA value of #00000000 and a simple integer value of 0. So why not find a way to short-circuit that? Paint.NET does not yet used a “tiled” memory management scheme for layer data, but there was still a very good, very simple, and very effective solution just begging to be implemented.

PDN images contain a header, a bunch of structural information (# of layers, etc.), and then a whole lot of raw pixel data compressed using GZIP. It isn’t one long GZIP stream, however. Each layer is broken up into 256 KB chunks which are compressed separately. This does increase the file size, but not by much (a percent or two), and it lets me compress each block in its own thread and makes saving a much faster ordeal than it otherwise would be. Save and load times are able to drop almost linearly with the number of CPU cores.

So yesterday, in the 4.0 code base, I fixed this scenario further. For regions of the image that contain “homogenous values,” which would be a 256 KB chunk of all the same color, I compress it once and then cache the result. The next time I find a region that has the same homogenous color pattern, I skip the compression altogether and emit the result of the previous time I compressed it. If a region isn’t “homogenous” then it’s discoverable pretty quick and therefore doesn’t waste much CPU time.

(These 256KB regions do not have any geometric shape associated with them, such as being a 128×128 tile. A 256KB chunk in an 800×600 image would be the first 81 rows, and then most of the 82nd row. The next chunk would start off near the end of the 82nd row, and then include almost the next 81 rows of pixel data.)

The result? About 50% faster save times! The first time you save the image will take the longest. After that the cache will be “warmed up” and saving is even faster, resulting in up to about a 90% reduction in save time.

This is a great optimization: there’s no change to the PDN format, so images saved in 4.0 are still completely compatible with earlier versions or with other applications that have done the grunt work to support PDN (I think GIMP does nowadays). It’s just faster.

Anyway, it’s been awhile since I posted. Fear not, work is still progressing on 4.0. Silence is just an indicator that I’ve been really busy, not abandonment. Ed Harvey has contributed a few really cool features that have been popular requests, such as the ability to use the Color Picker tool to sample all layers, and to sample the average from a 3×3, 5×5, 11×11, 33×33, or 55×55 region (apparently that’s what Photoshop does). He also added a few enhancements to the color wheel so you can use Ctrl, Alt, or Shift to constrain the hue, saturation, or value. I’ve finally added drag-and-drop to the Layers window for moving layers around, along with spiffy animations and transitions (it uses the same code from the newer image thumbnail list at the top of the window). I even added a setting to choose between the Blue theme (from 3.5) and a new Light/white theme (which is the new default). I’ve decided to cut some features in the interest of being able to finish and ship 4.0 this year, such as a plugin manager, but there’s always another train coming (4.1, 4.2, etc.) so I wouldn’t hold a memorial service just yet.

download.com “responds” to bad press about their malware

Sort of, anyway. They don’t touch the malware side of the issue at all. I got this in my inbox just now as part of their “Software Publisher Newsletter,” written by their Vice President & General Manager, Sean Murphy:

We are on the verge of fulfilling our vision of coming to market with an installer model that delivers files faster and more efficiently to users, while enabling developers to a) opt-in to the Installer, b) influence the offers tied to their files, c) gain reporting insight into the download funnel, and d) share in the revenue generated by the installer.

The ability to opt-in is not a feature request. It’s a Day 1 feature requirement. Download.com has been making money on other people’s software by barfing malware all over their customer’s systems (and by “their” I’m referring to the software authors).

Consider the Customer Experience Improvement Program (CEIP) that Microsoft has as part of Windows, Office, and numerous other software they release. It gathers information about how you use the software (e.g. which features you used, which buttons you clicked), and reports it to Microsoft. This clearly has enormous privacy implications. But, you have to opt-in to use it. The software asks clearly and politely if you’ll let them do this. The data is recorded in an anonymous manner. Things like permission and anonymity are not “features.” They are requirements.

Oh, and Microsoft actually uses that data to improve the software they release. Bazinga.

He continues:

First, on the press that surfaced yesterday: a developer expressed anger and frustration about our current model and how his file was being bundled. This was a mistake on our part and we apologize to the developer and user communities for the unrest it caused. As a rule, we do not bundle open source software and in addition to taking this developers file out of the installer flow, we have gone in and re-checked all open source files in our catalog.

Ok, whatever Sean. Nobody believes you. You’re not sorry about what you did, you’re sorry that people noticed and cared. You care that the bad press crossed a quantitative threshold, and that it just might affect your quarterly profit reports.

I wanted to verify that they had indeed fixed their catalog of open source software. VLC Player is, in fact, not being packed with their download wrapper (earlier blogs reported it was being bundled). Same goes for GIMP, GIMP Portable, and GTK+ 2 Runtime Environment (which are the first 3 hits if you search for “GIMP”). So from this tiny sample size of 4, it seems he is at least telling the truth for once. (I’d provide links to their pages on download.com, but I’d really rather not contribute to their page rank in any way.)

You can read the whole thing, if you’re really bored, over at their website.