Rick Brewster

Apparently so.

We changed the terminology from "foreground/background" to "primary/secondary" with our v2.5 release. The reasoning was that fg/bg had no relevance to how the colors were actually being used

We're looking to do a lot of things for our next major release. Hopefully this one will make the cut (in other words, hopefully we'll have time for it).

That error message leads me to believe you're using Paint.NET v2.5. I recommend updating to the latest version, which is v2.61, at which point it will work.

You might also try Evan's "Conditional Hue / Saturation" plugin, over in the Plugins section of the forum.

There are some specific cases that I've heard of where this does not in fact work correctly. It's generally due to the application being written incorrectly, or at least not written to take this in to account correctly.

Not that I'm aware of...

You can control the quality of a JPEG when you go to save it. It will tell you the resultant file size, which you can then use to determine what quality you want. Is that what you meant? If so, it's already there.

Like I said...

Allright, 2.61 is available and should fix this for you. I'd be interested to know how your deployment goes!

P.S. PNG's are lossless, there is no compression to configure

We're releasing this to fix a few of the bugs we've found since v2.6's release. This is not an alpha, beta, or release candidate, and as such does not expire. Get it via the built-in updater (File -> Updates -> Check Now), or on our website ( http://www.eecs.wsu.edu/paint.net ). Changes: * Fixed crash when clicking File->New when there is a malformed image in the clipboard * Fixed several obscure crashes related to drawing and pressing Ctrl+Z (Undo) or Ctrl+Y (Redo) before releasing the mouse button * Fixed Zoom Tool "haze" remaining after pressing Ctrl+Z before releasing mouse button * Fixed uninstaller not removing shortcut in Start->Programs * Fixed "Auto" button in Adjustments->Levels not updating one of its sliders * Fixed a few plugin API problems * Fixed rare race condition in file loading code related to EXIF tags * Added "Donate" item to Help menu Here's the post that announced v2.6: http://paintdotnet.12.forumer.com/viewtopic.php?t=994 Now it's back to Oblivion for me ... (the game, that is)

The default variable name that Tom gives is "rect", not "image". Anyway, you're right on that last point. Effects are not rendered all at once -- otherwise it would not be possible to do things like progressive rendering ("35% done"), multithreaded rendering, and clipping to a selection region. You should not use rect.Bottom as the bottom of the image. That rectangle defines the current rectangle that is being rendered. Paint.NET will divide the whole rendering area into 200 rectangles per logical processor (so 400 for your P4 w/ HT), and pass each one to the effect rendering function. Because of threading, multiple rectangles will be rendered in parallel, but you don't have anything that would have trouble with that (everything is self contained in your function). What you want is maxy = dst.Height-1.

Three things... 1. You didn't state what results you're getting, just that it's "not working right". So you have no idea what is wrong, but neither do I! 2. "Maximum Y" and "Bottom" are different things. Maximum Y is Bottom-1, so you should do "maxy = image.Bottom - 1 3. This code assumes you are working with opaque pixels. What you should do is calculate an intermediate alpha value, "a" the same way you are currently calculating PixelColor.A. Then, "PixelColor.A = (PixelColor.A * a) / 255;" (plus any type casts that are necessary). This will properly compute the new alpha for pixels whos original alpha value is not 255. (... and why is the rectangle named 'image' ? It should be called roi (for rectangle-of-interest))

Paint.NET does not support Wacom tablets, but does support Tablet PC's.

What in the world is up with the forums today ... last time it posted it 5 times in response to 1 click. (deleted the dup post, btw)

Also, with regard to the text rendering. We used to utilize GDI+ to do text rendering (w/ the Text Tool), but had many people complain about its quality of rendering, esp. at smaller font sizes. Currently we use GDI, and are now getting a different set of complaints. Darned if we do, darned if we don't, eh? It's basically rendering the text the same way Windows does for the UI in the rest of the system (windows, dialog boxes, text on a web page, etc.) Expect to see more options in this area as well, even if it's just to choose between "smoothing option A" (GDI) and "smoothing option B" (GDI+). The big benefit we get currently from using GDI (instead of GDI+) is that it is now possible to use Paint.NET for doing UI mockups. Basically you take a screenshot of a dialog box, then edit the text to be something else for the purpose of a design document or Powerpoint presentation. But we're realizing over time that this does not produce palatable results for many other types of image editing.

This is definitely something we're looking into for our next major release, look for major improvements here. I totally want to rewrite so much of this stuff. (like said elsewhere, it takes time -- so don't hold your breath please) Right now we use GDI and GDI+ for most of our rendering. GDI+ in particular is known to be buggy, but most apps stick to the simple stuff that doesn't cause problems ("draw bitmap" and "fill rectangle" type stuff). However, we've come to the point where it feels like we're running in to every bug in GDI+. For example, just two days ago I found a bug that only happens in 64-bit mode. Draw a rectangle with a brush size of like ... 8. Oops. The corners are not mitered at all so you end up with a poor "rounded" rectangle. This is GDI+'s fault. grumbles and mutters I remember reading some quote from a guy working on Office, it was something like: "Find the dependencies ... and eliminate them." Expect us to use GDI+ less and less as time goes on, which will give us more flexibility and power as a result.

Except that those 4 PNG's would not retain blending modes, opacity, metadata, or anything else we choose to add in the future. Layer masks, text layers, layers-as-adjustments, adjustments-attached-to-layers, composite layers, annotations, who knows. PDN is a pretty general purpose file format. Going by the numbers, right now it only adds blending modes and opacities to the mix (oh and a "Visible" checkbox), but those are pretty important benefits. It would also be annoying to have to re-import those 4 PNG's every time you wanted to edit them as a group. Computers are very good at remembering and automating things, so it makes sense to take advantage of that, even if only "a little." (Regarding the metadata: Yes, other file formats provide metadata. However, PDN has metadata for the image as a whole that is not restricted to EXIF, as well as per-layer metadata. The latter is neither used nor exposed in the UI yet, and the former is not editable yet. But the capability is there, and is just one example.)

I'm not really sure what you're getting at here. .PDN isn't mean to be an interoperability standard, like for display on web pages or anything, just like .PSD [for Photoshop] isn't. PDN isn't worth it if you're just saving a 1 layer image, that's true. Because of this, we default to suggesting .PNG in the Save dialog when saving a 1 layer image. We only suggest .PDN when there are 2 or more layers. Not saving the history data is just the currently feasible level of functionality we have. Maybe someday it will make sense to do this, but right now it is not.

Out of curiosity, what Windows language are you using? (I'm using English, for instance)

Looks like you're out of memory.

While that crash dialog is up, open the following directory (via Start->Run is probably quickest): %TEMP%\PdnSetup What files are in there?

The issue is that there is currently no way in Paint.NET to transform the alpha channel of an image in the way that Jonelmeier wants. (except with C# code in CodeLab -- hardly a robust solution) What he wants is a layer mask. Basically it would be another layer contained within the layer he is editing which would then be used to transform the alpha channel of the color portion of the layer. This way you could draw a gradient on the mask using the method of your choice, and it would then be combined into the regular part of the layer and it would fade to transparent. This is something I'm hoping to implement for the next major release of Paint.NET. Just don't hold your breath, these things take a lot of time.

The history was never designed to be persistable. Plus, if we were to save the history with the PDN file, we wouldn't be able to change how things work in the future. This would prevent us from adding, removing, or changing things (or fixing things!). For example, if we wanted to rewrite the line drawing tool, it would probably need to store different data in its history action. But our hands would be tied, because the format was already set in stone. We could write code to migrate the history data between different schema versions, but that just doesn't scale with 2 developers and tens of history action types. We'd spend all of our time figuring out data migration issues instead of adding, changing, or fixing things. Which leads to the next problem. Maybe we'd just discard the history when we did change things, but that would also be obnoxious (I can imagine the e-mails now ... "I upgraded PDN and my history disappeared!!! BUG!"). Of course you may point out that we do persist history data to a temp directory while Paint.NET is running. It looks like every history action results in 1 file in that directory. This is partially true, but also misleading: not all history actions save their data to disk. And those that do only save the "big" portions of their data (e.g., large bitmap regions). And even then, they are still coupled to the rest of the history action that resides in memory. We do this to relieve memory pressure, as otherwise you could run out very quickly. Just try using Paint.NET v2.0 for awhile and you'll see the memory usage keeps going up and up and up. And yeah, it would result in huge files. Or we'd save two files, a .pdn and a .pdn_hist or something, and there'd be the possibility of mismatches between the two. It would just be a huge nightmare. So, in summary, not saving the history is the lesser of all evils or nightmares. Sorry guys. I of course agree that it would be Very Cool.