The Paint Bucket in 4.0 (video)

This video showcases some of the things I can do with the new rendering engine and tool transaction system in 4.0. Even the Paint Bucket tool can get awesome “WYSIWIGEWYEI” (What You See Is What You Get … Especially While You’re Editing It, which needs a better name) and Fine-Grained History (you can undo/redo every change, not just those that commit pixels to the layer).

One big annoyance of the Paint Bucket tool in every imaging app out there is that it doesn’t do a good job of letting you explore and be creative. There are two primary “inputs” for it: the origin point (where you clicked), and the tolerance setting. Where you click determines the point at which the flood fill algorithm is executed from, and which color is used as the basis for comparing to other colors to see if they are at a “distance” (Euclidean) that is less than the tolerance value. Colors that are at a distance less than the tolerance are filled in with whatever color or pattern you specify. Black and white are as far apart as possible and require a high tolerance value to “notice” each other, while shades of the same color are computed as relatively close to each other and will be included with lower tolerance values.

What happens in most imaging apps* is that you click somewhere with the Paint Bucket tool, look at the result, and decide that either you wish you’d clicked somewhere else or used another tolerance value. On a rare occasion, it looks perfect and you’re done.

Then you click undo.

Next, you click somewhere else, possibly after editing the tolerance in the toolbar. Then you realize it’s not exactly what you want, so …

Then you click undo. And repeat. And repeat, and repeat, and repeat.

In 4.0 I’m working to finally get rid of that repetition, which is work I started with the new Gradient tool I added back in 3.0 (2006!). Once you click somewhere with the Paint Bucket tool, you can go edit the tolerance in the toolbar which essentially causes your click action to be re-executed. You can also move your mouse down into the canvas where you clicked, and drag around a handle which will move the origin point. You can change the color, or anything else that affects how the fill is rendered. You can use the undo and redo commands to walk through every adjustment that you’re trying out.

This is a very powerful addition to the tools in which really enables you to quickly explore the creative landscape in a way that no other image editing software can. It also lets you gain an intuitive understanding of settings that do not necessarily lend themselves to short, intuitive descriptions (like tolerance!), but which are easily learned through interactive exploration. This video was recorded a few weeks ago. Since then I’ve added antialiasing as well as the ability to choose between sampling the current layer or the whole image, and have also made other performance improvements. (I’ve also removed the “old” Paint Bucket tool, which is why you see the “new” version of it sitting at the bottom of the Tools window in the video.)

This is my first video posting, we’ll see how it goes! I didn’t think I could properly discuss this feature with just words and pictures.

* every one that I know of, but I used the word “most” just in case I’m wrong Winking smile


63 thoughts on “The Paint Bucket in 4.0 (video)

  1. Romanos Nianios says:

    Hey nice video, please keep us inform with videos about the new features you implement in the Paint.Net 4.0 😀

  2. says:

    Wow, this is awesome! Congrats on such a great feature.
    I wonder if this will appear in Photoshop CS7 and Adobe will call it a unique and exclusive feature :p

  3. scutterman says:

    This looks absolutely amazing. I use GIMP at the moment, largely because it allows me editable text layers, but I’ve been following this blog and keeping track of new features. When 4.0 ships, or at least enters into alpha or beta release, I’ll definitely be giving it a go.

  4. Andrew says:

    w00t! Looking forward to 4.0, and in the meantime looking forward to more cool blog posts!

    Paint.NET is easily my favorite piece of freeware. Thanks for putting out something so powerful that actually has a decent UI! Thanks for working on this in your spare time and sharing it with the world.

    My only question is how best to ingratiate myself to you so I can help out 🙂 (I’ve followed the history and have read why you closed the source–don’t blame you–but it kills a graphics/GUI-oriented .NET developer to know there’s this amazing library of graphics code in C# that the developer was willing to share until thieving weasels ruined it for everyone.)

    I’ve played with the plugin interface a bit and love it–just wish more of the API was exposed/more types of plugins were allowed. Have you considered exposing any more parts of the app to plugin development in 4.0+? (I understand that everything you expose via an API limits what you can freely change in future versions.)

    • Rick Brewster says:

      I’ve had to take a machete to the feature list for 4.0, which included cutting any improvements or additions to the plugin API. I’m planning on placing a heavy emphasis on plugins for the 4.1 release, with improvements for both users (installation!) and developers. The new rendering engine in 4.0 is quite powerful and I’ve just got to find a way to allow plugins to make use of it better.

      • Andrew says:

        Cool, thanks for the info! Are pluggable tools a possibility down the road, or would that expose too much of the guts?

        • Rick Brewster says:

          A technical possibility, yes. I’m just not sure I have a safe enough API for developers to use yet. While the new system is massively better than the old one, it’s still too easy to get things wrong in a way that is too hard to debug. I’d probably start with the ability to add new things to existing tools, like programmatically generated shapes/brushes which can then live inside of a comfy house without sharp edges all over the place. Then you’d get all the benefits of the new shape tool’s UI (not written yet), such as draw-then-manipulate-before-commit.

      • joaonc says:

        Is that because PDN 4 is not 100% .NET or is it b/c .NET 4.0+ doesn’t jive well in Mono?

        • Andrew says:

          joaonc, much of what is available to .NET apps on Windows is provided via thin wrappers around existing Windows APIs, such that an app can be in one sense “100% .NET” (e.g. written entirely in C#) and still make use of libraries that haven’t been implemented by the Mono folks. For instance, even the GDI+ drawing API along with associated classes like Bitmap were just wrappers around Windows functionality. The Mono people made their own implementation of GDI+ with a C API and than wrapped that in .NET as you can read about here:

          All of this was a lot of work for the Mono people, and it’s my understanding that they essentially abandoned their attempts to keep up with Microsoft’s ever-changing UI APIs after the switch from Windows Forms to XAML/WPF.

          Rick has mentioned several Windows-specific technologies he’s taking advantage of for Paint.NET 4.0 that to the best of my knowledge aren’t yet, and may never be, implemented in Mono. If I understand correctly, the new UI uses WPF and the drawing code relies heavily on Direct2D.

        • Rick Brewster says:

          What Andrew said, although a few clarifications. PDN4 doesn’t use WPF for UI, although it does use some of the lower-level WPF facilities such as the dependency property and data binding system. I have my own UI framework now for the canvas (e.g. move handles and such), and while it’s not WPF it is very, very similar to it.

          Now imagine writing cross-platform wrappers for not just GDI+ but Direct2D, DirectWrite, DXGI, Windows Animation Manager, and Windows Imaging Component (WIC). Theoretically it’s possible, but it’s just not going to happen 🙂

          • Olivier DALET says:

            “although it does use some of the lower-level WPF facilities such as the dependency property and data binding system”

            This is an interesting piece of information I wasn’t aware of! And something I had in mind for quite a long time, making use of WPF binding facilities but yet keeping good old Winforms… Do you have some sort of adapters between Winforms binding and WPF one?

            • Rick Brewster says:

              I’m not mixing WinForms controls and Dependency Properties. I’m using them on objects that serve more of a ViewModel (MVVM) role, and in my UI toolkit which mirrors WPF’s object model and architecture (System.Windows.Media becomes PaintDotNet.UI.Media, for instance).

              All you need is to derive a class from DependencyObject or Freezable, and add dependency properties to it just like you would in WPF. Data bindings can be set up in code using System.Windows.Data.BindingOperations.SetBinding(). You can also use SetBinding() if your objects implement INotifyPropertyChanged, which should let you bind directly between WinForms controls (actually I think you need to either implement INotifyPropertyChanged, or each property must have a corresponding FooChanged event, and I’m pretty sure all the important WinForms properties do).

              • Olivier DALET says:

                Thanks for sharing this! Gives me ideas (I don’t plan to compete with Pdn) for a project at work in which we have a now aging control allowing for simple image cropping, resizing…

  5. Myoo says:

    This looks amazing, it will save so much time.
    Small question, will we be able to do this with the magic wand as well?

  6. Nathaniel says:

    Ooh, that’s an awesome bit of usability enhancement… would be really cool to apply this concept to the magic wand too.

    • Rick Brewster says:

      See Myoo’s comment above 🙂 The main sticking point right now is figuring out a good way to add antialiasing to the magic wand. The selection system is currently 100% based on geometry, and so I can’t just provide the same alpha mask that the Paint Bucket computes. That’s also what prevents me from implementing stuff like feathering. Some day!

      • froyton says:

        I’ll be the fourth, then. With all the software engineers Adobe and the like no doubt have working around the clock, there is no excuse for them to not have done something like this already. They should have to pay you a license fee to implement it. 😛

        For real, this feature looks really great. I really dig the whole idea of converting click-and-you’re-done tools into tweak-before-commit tools.

        • Rick Brewster says:

          Yeah I’m torn between disliking patents in general, versus making others sweat. If I do patent it, it becomes a Paint.NET exclusive and is also helpful for my career. If I don’t patent it, then others have to play catch up, and that’s good because it’ll take them awhile 😉

          Here’s some interesting trivia for the new tweak-before-commit system, as you call it. I converted the Pencil tool to the new transaction-based system. It didn’t need to be converted, it’s not like it does much, but it was a very useful exercise and helped to provide more validation for the new transaction system. Anyway, the pencil tool is still click-and-you’re-done, but I had to add special code so it could commit without adding an extra history item (first one for draw, second one for commit). When I first wrote it, you could go and “tweak” what you drew with the pencil tool by clicking Undo and stepping back through the commit. You couldn’t move it, since I didn’t have a UI for that, but you could edit things like the color and the blend mode. At some point maybe I’ll add a dropdown button in the toolbar to control the “commit mode” for each tool. “Auto-commit after drawing” versus “Allow editing before committing.” The default value can be tool-specific, so the pencil tool would still default to commit-on-mouse-up, and that ensures that common scenarios still behave as expected. But I still want the powerful ability to control when the commit happens. We’ll see … at this point it’s a UI design problem, not a technical one 🙂 (not happening for 4.0!)

          • Robert Clark says:

            I really hope you do patent it, this looks like an incredible feature and seeing some company rip this idea off from you and charge untold amounts for it would be a very sad sight. This looks like a really innovative feature, and I personally can’t wait to use it, it will make some of my work so much easier and I don’t even know where to start to thank you for that!

            • ppc says:

              This feature already exists in adobe after effects and other compositing programs, so the idea is not new…

              • Rick Brewster says:

                Cool 🙂 Do all the tools work like that, or only some? (in Paint.NET this functionality is generalized so that all tools can use it — once I’ve upgraded them of course)

                I wonder why they haven’t ported that functionality over to Photoshop. Its gradient tool in particular is maddeningly frustrating to use.

              • ppc says:

                Most compositing programs works with different (object-oriented) logic. Everything like tools, effects, actions etc. is just objects with editable properties. Αny changes you make to the properties of the object, you see the result in real time. In after effects the paint bucket is a realtime effect.

              • Andrew says:

                So this “fine-grained history” business has got me thinking about the varying levels of detail a user wants in his/her undo stack in different contexts. We did a geospatial data collection app at work with two levels of undo: undo within a tool and undo of committed operations. As an example, a user drawing a polygon may want to be able to walk back through the history of vertices drawn to fix a mistake. But once a user has committed an action (in this example by double-clicking to close off a polygon), it’s unlikely that they’ll want their permanent undo history to contain every vertex ever drawn. That is, if you want to undo a change you made *before* drawing that polygon, you probably don’t want to have to undo 200 vertices to get back to it. So we had a within-tool undo stack and a document-level undo stack. Selecting “Undo” in the app (or hitting Ctrl-Z) would check whether there was anything in the current tool’s undo stack and, if so, undo it. Otherwise, it would undo the last document-level action. This worked for the most part, except when the users accidentally committed something they didn’t mean to, at which point what they really wanted was to “undo the commit” and get back into the tool where they left off. We ended up adding a separate feature for this “uncommit” sort of undo.

                In Paint.NET 4, what will Ctrl-Z do if I’ve just committed the paint bucket? Will it undo the commit, such that successive Ctrl-Z’s move me back through all the temporary changes I made with the paint bucket, or will it position me in the history prior to my selection of the paint bucket tool? I think there’s a good case for having it do the latter. The full history would still be there via the History palette, but I think it would be a good assumption that once I’ve committed changes, I want “Undo” to step me back through my committed changes. (I suppose if it works the other way, I’ll get used to going directly to the History palette for such work, but my gut says this is the more common use case.)

    • Rick Brewster says:

      Once I’ve finished upgrading the tools to the new transaction system and rendering engine, I plan on releasing an alpha or beta. I’d give an estimate but I’ve always been wrong about it. I was hoping to have something in time for Win8 GA (General Availability, Oct. 26th), but that turned out to be unrealistic, and constantly pushing myself to try and meet it had bad consequences (burnout is not fun), so I’ve relaxed my time commitment on it.

  7. Saif says:

    Lot of features in is very impressive and which make all love to used first than Photoshop for minor things now.

  8. Lars Jensen says:

    Nice new capability. While you’re messing around with the paint bucket, I’ve always wanted it to behave like a real paint bucket in the sense that I could drag it to fill neighboring regions with the same color value. This would give the same result as clicking in each region in turn, but it would be more interactive and that much faster. The tolerance value is another approach to a similar end, but I often find that adjusting tolerance doesn’t quite cut it. Sometimes you have to play with the tolerance to get the right value (which your work described above should address nicely), but other times there is no single tolerance value that will give the desired results.

  9. MercWithMouth says:

    Wow. This looks great. Please, keep up the great work! I’m really looking forward to the release of the new Paint.NET!

  10. jbgray says:

    Awesome work, Rick! This is the best-designed bucket tool I’ve seen—certainly the only one that lets you tweak the location and tolerance interactively before committing to a colour fill.

  11. HamRadio says:

    This is great! Thanks for the great program, I use it all the time. Although regarding the comments about you patenting, I vote you go Open Source 🙂 Give Gimp a run for their money 🙂 Thanks again!

  12. Luke says:

    Just wanted to say I can’t wait for the new I have a scenario where this new functionality for the paint bucket would work perfectly! Keep up the great work!

  13. MrZackarius says:

    Have you ever considered making a mobile version of Just curious.

  14. Rob Brown says:

    How about calling it something like “Live Preview” or “Real-time Editing”?

    I’ve not got speakers here, so you may mention this in the video, but it strikes me as similar to the Fuzzy Select tool in GIMP and the fact that you can drag the mouse around (with the left-button held down) whilst selecting an area to alter the threshold – which is a very useful feature.

    Keep up the good work Rick – Paint.Net is still one of my favourite applications 🙂

Comments are closed.