Rick Brewster

I'm not answering a legal-related question just because you're "curious". What you're asking requires me to make a decision and set a policy on something that has real consequences. Please stop asking questions whose answers would either be completely speculative (icon for 4.0? seriously?!), or that you don't actually need an answer to (like this one). Thread Closed

There has never been an official "portable" mode for Paint.NET. You haven't described how you have been achieving this, and we are not psychic unfortunately. (I don't know what "uniextract" is)

It does maintain a visually effective hierarchy. It was well thought out by Tom Jackson when he originally implemented it, and it's worked very well for the years that it's been in place. You may simply need to change the resolution (DPI) in Image->Resize while you are editing the image in order to virtualize a more granular ruler. (i.o.w., set the resolution to 10x, then you'll see 70, 71, ... 79, 80 in place of 7, ...., 8) Well hey you're the expert right?

No. It's not in the change list ...

Images need to be quick to load and save. Using excessive compression defeats that purpose. Storage is cheap, and network speed is always improving. Unless you're trying to cram a bunch of images onto a 3.5" floppy disk, I really don't see the point. Paint.NET uses GZIP for compressing the bitmap data in .PDN files. One of the reasons for using GZIP is because it's simple, fast, and provides a reasonable amount of compression. This is mostly important so that featureless layers (e.g. a blank layer) don't have to contribute much to the file's size. The simplicity of the algorithm is a genuine advantage. If necessary, I could probably implement it myself instead of relying on the SharpZipLib DLL -- this is important in the event that a critical bug (or legal issue) is discovered in their implementation. There's no way I could implement something like LZMA myself, however. If you really need to compress an image further, JPEG is available which gives you the ability to compromise quality for storage. For PNG's, tools such as PNGOUT and optipng are good for final post-processing before uploading; they are not practical to use while authoring the images, however, as they take a significant amount of time to process an image. So, while your idea is a decent one, it simply falls victim to the good-enough-is-good-enough strategies that have already been ubiquitously implemented.

Because it used to be an EXE/MSI and people got corrupt downloads for whatever reason (usually because their NIC was junk). Now they'll know right away because their ZIP program will tell them and it'll be obvious that the download was bad and nothing else, instead of having to wait until the app starts randomly crashing or behaving erratically, or when the installer barfs out some incomprehensible error message. And because some antivirus or "security" software or proxies don't like letting people download EXE files directly. You should not presume that things are at an "unnecessary level of complexity" simply because the reasoning is not apparent to you

Just download the plugin.

Paint.NET is written mostly in C#. Should be pretty obvious what compiler is used from that simple fact ... ... and even then, I don't buy into conspiracy theories like what you linked to. So the compiler checks the CPUID string, so what? You cannot necessarily expect the developers at Intel to buy a big lot of AMD chips and double the amount of testing they perform on their exotic optimizations (or put another way, you cannot expect Intel's accounting department to fund that). Or maybe they did, and found out that the AMD chips don't execute those specific combinations of instructions correctly. I don't know, and it doesn't matter. In either case the safe bet is to rely on a more pedestrian code path. Thread Closed

Try pinning it. Right click -> Pin to ___whatever___.

... Assuming you have the $100 printer and everything Good intentions though, and it could help some people out.

:shock: Have you even looked at the release notes on the website?! 3.5.x is a significant upgrade over 3.36. In fact, some egregious performance issues were stomped out of the Magic Wand tool and the selection outline renderer. http://www.getpaint.net/roadmap.html http://blog.getpaint.net It does use less memory. That is a fact. There are three things you should know, however. One, the reduction in memory usage is only apparent when multiple images are opened. If you're only working with 1 image (albeit with "many" layers), there may not be much difference. Second, is that a memory leak was just fixed in the v3.5.2 release (I just uploaded it a few minutes ago). It may have been affecting you. Third, on a 32-bit system you will always be limited no matter what. If you are using Paint.NET for important things™, then in my opinion you should also upgrade to a 64-bit OS. Paint.NET is much happier and faster on a 64-bit system, and the likelihood of getting an out-of-memory error or crash becomes slim.

This update resolves some feature disparities in the Text tool between GDI (XP) and DirectWrite (Win7/Vista). It also improves overall performance, as well as the correctness and quality of the Move Selected Pixels tool, the Image->Resize function, and the Hue/Saturation adjustment. As usual there are two ways to get it: 1. Download directly from the website, http://www.getpaint.net/ . There is no need to uninstall the old version; that will be taken care of automatically. 2. Preferred: Use the built-in updater from within Paint.NET. You can go to Utilities->Check for Updates, or you can wait for the following update dialog to show up automatically within the next week or so: Changes and fixes since v3.5.1: * All font face variants (e.g., Arial vs. Arial Narrow) are now available with the Text tool in Win7/Vista with DirectWrite. * Bitmap font types (e.g. Courier, Terminal, Fixedsys) are now available with the Text tool in Win7/Vista. * Fixed some bad text kerning with the Text tool at small font sizes when antialiasing was turned off. * For the Image->Resize function, the quality, correctness, and performance of Bilinear and Bicubic sampling modes have been improved. Super Sampling also has some performance improvement. * Improved the rendering quality for the Hue/Saturation adjustment. Also made a new icon for it. * Fixed many subtle rendering issues with the Move Selected Pixels tool. These were apparent when flipping or rotating a selected area. * Fixed: The Line/Curve tool was applying pixel snapping to the curve nodes, which caused lines to "bend" when using the Shift key to constrain the angle. * Fixed some extraneous CPU usage related to unnecessary or redundant thumbnail updates. * Fixed a few dialogs that looked wrong with Aero glass with Remote Desktop or Virtual PC. * Fixed a nasty memory leak with Flatten followed by Undo. * Fixed some issues related to effects that took awhile to cancel. As it turns out, drag-and-drop was enabled at this time, which easily lead to crashes or hangs. * Some Win7 systems could not detect that .NET 3.5 SP1 was installed, even though it was. A fallback detection function has been added. * For plugin authors, the Effect class now has a pollable IsCancelRequested property. This can be used to improve responsiveness for expensive OnSetRenderInfo() implementations which are otherwise non-interruptible. * For plugin authors, the Surface.FitSurface() method is now optimized to use multiple threads, which improves performance.

I'll need a sample image from your workflow to be able to investigate this at all. On all the images I've worked on, the selection outline is always clearly visible. Actually I found one case where it wasn't, but it was only when the pixel grid (View -> Pixel Grid) was enabled.

Don't know. I've never tried that tool.

Clearly this isn't going anywhere. Thread Closed

That's because you do have changes that you might be interested in saving. They just happen to be in the redo list. This is 100% intentional.

I wouldn't be so presumptuous when talking about my programming. If you don't have anything useful to add to a troubleshooting thread, then don't reply to it.

PLEASE STOP SHOUTING. You'll need to edit the title of your thread. Otherwise I will have to close this.

You'll have to be a bit more precise than that. Why would the app be changing the tolerance "on the fly" for you? Like a "smart" tolerance thing, or just a keyboard shortcut?

Are you asking becase you actually want to do this, or just out of curiosity?

Why would installing the WIA Automation Library help at all...?

Another thing worth trying is to install the latest Visual C++ 2008 SP1 runtimes. The one available from the Microsoft download center is not actually the latest version. You'll need version 9.0.30729.4148. Paint.NET does install it, but apparently things don't always work the way they're supposed to. If you are on 64-bit (x64), install both. Otherwise just install the 32-bit (x86) version. These files are digitally signed by Microsoft -- they are not something that I packaged up, I've only made them available for download here for troubleshooting purposes. Each file is about 5MB. Visual C++ 2008 SP1 Runtimes, version 9.0.30729.4148 x86: http://www.getpaint.net/files/vcredist/ ... st_x86.exe x64: http://www.getpaint.net/files/vcredist/ ... st_x64.exe

Hey, welcome to the forums. Please make sure to read the rules though -- especially [rule=6]the 6th one[/rule]. Then, please modify your thread title accordingly. It's important for keeping things organized around here. Otherwise I'll have to close the thread, unfortunately.

Umm ... who knows. And why do you keep asking questions about things that both don't matter, and which are waaaaaaay off in the future ... Be happy with what you have now. Thread Closed

"Smooth" is just a bilinear resampling (triangle filter). In order to do the math correctly, however, you need to work with the pixel centers. Basically, add 0.5 to the dstX/dstY, then translate to the srcX/srcY, then subtract 0.5. Otherwise you'll have all sorts of confusing issues with "black borders" and no amount of fudging or kludges will really fix it all. for (int dstY = 0; dstY { double srcY = (((dstY + 0.5) * srcHeight) / dstHeight) - 0.5; for (int dstX = 0; dstX { double srcX = (((dstX + 0.5) * srcWidth) / dstWidth) - 0.5; ... normal bilinear sampling kernel goes here ... } } Also, the Move Selected Pixels tool has some fixes coming in v3.5.2. So does Image->Resize. As far as automation or batch processing, that isn't currently possible with Paint.NET.