Rick Brewster

Because.

EER, c'mon man. Psychic powers ... use 'em!

That's just the way it works.

Paint.NET has zoom in/out, and Windows comes with the magnifier. If your computer's too slow to run the latter well then I'd look at getting a faster computer. Try doing an online search too. You might find some other utility that does what you want.

The VC8 runtimes are something that a part of .NET is linked against, iirc. They should be installed along with a correctly installed .NET 3.5 SP1.

Looks like pretty serious out of memory there. Removing a subscription from an event delegate generally doesn't need much memory. Also, it looks like this happened while Paint.NET was shutting down. Upgrade to 64-bit Windows, problem solved. Kudos for being on Win7 though.

If you have questions about that plugin then you need to go ask in the thread for that plugin. Closed

That's not a bug. That's a plugin wanting you to update it, not Paint.NET itself.

That's just what the error message says; it's not his analysis.

And, also, you may not distribute Paint.NET itself in this manner.

No, you shouldn't be doing anything to the Paint.NET UI. Effect plugins are for rendering content to a layer. FileType plugins are for bringing in content from a stream. When you try to go outside these boundaries you introduce side effects that may cause Paint.NET to get confused, or users to get confused. Or if your error handling isn't perfect, things can crash or do other stuff. You also make it much more difficult for me going forward to ensure compatibility with your plugin. You may have something that works with whatever the latest version is, but you have no guarantee that later versions of Paint.NET will respond to what you're doing (or that it'll respond correctly, or that it'll respond to the restore command, etc). If you do stuff like this, I'm much more likely to just block your plugin from loading than I am to ensure it still works in the next version.

Why not just use a regular screenshot utility? There are a bajillion of them.

The Photo Print dialog doesn't give you a way to specify its location. No can do. The File Open/Save dialogs do it automatically; they are part of Windows. And yeah, how do you know it's "a few lines of code to implement"? Don't say that. You don't know that. It's patronizing.

Is it me or did this thread precisely recreate my hypothetical conversation from the Rules

You're writing a Paint.NET plugin?

Please remember to post in the right section of the forum. Thanks. Moved to Troubleshooting

Paint.NET isn't actually destroying anything: when you resize the image it must blend together neighboring pixels. When those pixels have an alpha value of zero, everything multiplies together to zero and also gets divided by zero. Zero is zero is zero is zero is zero. This is just math. The information simply isn't there and cannot be psychically extracted, nor can an accurate guess be made. The problem you're seeing stems from the fact that normal maps and color bitmaps are overloaded onto the same storage format. The "RGB" in the image is coerced to be XYZ by other tools and renderers, because historically it was very convenient to simply use the same tools and file formats for both. There is no bug in Paint.NET. It is performing correct calculations on RGB+A pixels exactly the way it was designed to do. The fact that normal maps are actually XYZ instead of RGB is an artifact of other tools that want to leverage RGB-based tools (which in general has been a smart thing). There is no XYZ alpha composition calculus out there. Maybe you simply shouldn't be using the alpha channel for images which will then be used as normal maps.

Oh I see what you mean -- originally you said, But now you're saying that this happens when the alpha channel is 0. Well, the truth is, this is how the math works out when doing correct alpha composition. When alpha is zero, it doesn't matter at all -- mathematically speaking -- what the values of the R, G, or B channels are. Fully transparent is fully transparent. Also, the math doesn't work out to even allow a meaningful R,G,B value to be computed -- it's undefined, but the computer can't actually represent "undefined", so instead Paint.NET uses 0. I could've picked lime green or purple, which are popular colors for apps that use a "transparency key" type system, but in the end it's still a completely arbitrary choice that not everyone would agree with. To make it customizable would greatly reduce performance, as the customized color "key" would have to be referenced for every pixel operation (even a 1024 x 1024 image has over 1 million pixels). Thus, the problem is actually with the other tool you are using and how it is interpreting an Alpha=0 pixel value. It does not appear to be doing correct alpha blending, which would treat all Alpha=0 color values as equivalent (completely transparent, in other words).

Seems like you may have a bad or corrupted font. Which font? Does its preview show up in the font list in the toolbar? ("The quick brown fox ...")

It's showing up as black in Paint.NET, or in another application? Please provide a screenshot, and a sample image that reproduces the problem.

How is it stupid?

That's not really the same thing though -- it's stretching the pixels around, and the result is sub-optimal. This is something I've already been planning to do for v4.0.

"Merge with Overwrite" wouldn't be possible anyway because it would require a 2nd alpha channel (or a system for doing masks)

This cannot be done with a plugin.

Nope. Use a CAD program ...