Rick Brewster

He's also quoting a post from 3+ years ago.

While the update is in progress, you can find it in %TEMP%. It'll be called something like Paint.NET.3.5.4.Update.exe, about 3.1mb. This is NOT exactly what's on the website, btw. It'll run just fine on a system that already has Paint.NET v3.5+ installed on it, however. It omits about 1.5MB worth of prerequisites that are only needed on a system lacking .NET 3.5 SP1 and/or Windows Installer 3.1. But, really, the best method is to just grab it off the website.

Well, there were no changes to install/update in the latest v3.5.4 update. Sometimes a change in version does magically work though *shrug*

Won't work if they're on a domain. (Yet another reason to upgrade past XP, btw -- Vista/Win7 can do both FUS and domain join.)

For unattended installation you shouldn't use the MSI. Run the installer with /auto. Paint.NET's MSI is for large-scale network deployment via AD/GPO, and does not support auto-update.

I have no idea what you're talking about here. Maybe that's the cause. Just run the normal installer!

Nope.

You didn't understand a thing I said. Anyway I've already explained what's going on here. There is no need for further discussion. Thread Closed

All installation files are required to be present. The reason is that, for whatever reason, sometimes people accidentally delete these files (or they get deleted by some other means). There is no way to detect whether a file is missing accidentally or on purpose. So, all installation files are required to be present. If this were not the case, then many non-English users would inadvertently be unable to have the program in their language. This system is also in place to protect other files (dll, exe), which sometimes suffer the same fate. The net effect on you is zero. The disk space consumed is negligible, and the only other effect is the size of the Utilities->Language sub-menu.

There is no Paint.NET Facebook page. How is that page illegal? It's not like it says it's an official page or sponsored or whatever.

We won't do the image for you, but we can answer any questions you have about doing it yourself. (This is absolutely not a "for hire" forum -- paid or free.)

You can also go here, http://www.hanselman.com/smallestdotnet/

Also, worth pointing out is that the article itself may not even be correct. He talks at long length about using gamma of, say, 2.2. However, reading up on sRGB at Wikipedia shows that a non-constant/non-linear gamma exponent is actually correct. Which of course makes things even more difficult and worse. 2.2 Actual sRGB

Moved to Troubleshooting

You can still drag multiple images on to Paint.NET itself when it's open. Or right-click on the batch of images and click Edit, or Open With -> Paint.NET.

I've seen a lot of things in movies that we wouldn't allow on this board, foobar.

Update to Paint.NET v3.5.4.

By "bigger", you're referring to the file size?

There isn't really a bug. That article is partly sensationalism. Mathematically it has many true statements in it, but the problem isn't nearly as profound as is claimed. Gamma is a multivariable function involving the image source (camera), image file, and display/configuration. Some images don't even specify their gamma scale, and many monitors are incorrectly configured. Making assumptions at any point ends up ruining things, and adding lots of configuration options (e.g., "assume gamma of [x] 1.8 [ ] 2.2") can just add confusion. Resampling methods in Paint.NET, such as bilinear and bicubic, do not take gamma into account. They use a linear scale, as correctly stated in that article. However, it's not always clear what gamma scale should be used. Even if the image says it has a gamma of "A", and the monitor says "B", there's really no guarantee that these values are correct. Or, even if it's correct for my monitor then it'll be wrong when I send it over to your computer. Or, even if you apply consistent post-processing only when displaying the image, some other tool along the chain will mess it up. For example, if the Win7 Photo Viewer is correctly adjusting for image vs. monitor gamma (which I think it does), and you take a screenshot (Print-Screen), then that gamma information is not stored in the clipboard. So you get runaway gamma application as image data moves from tool to tool. The solution could be worse than the problem in that case. It's kind of a darned-if-you-do-darned-if-you-don't situation.

Paint.NET does this because it's apparently what the GDI+ codecs do. Behavior may be different in Win7, where the GDI+ codecs were rewritten to be wrappers over WIC.

The hide/show functionality in the Win7 font manager only affects its built-in WordPad and Paint, from what I recall. There is no way to use this information in Paint.NET, or other applications.

Paint.NET has nothing to do with Javascript. There is clearly a misunderstanding somewhere. Paint.NET is just a normal desktop/client application. It does not require a web browser or Internet connection. This is another misunderstanding. The name is similar, but it is not going to be its replacement.

Maybe you should fix your plugin then.

TIFF isn't really meant for photographs. It's an old file format that is really only used for multipage faxes nowadays. PNG is superior in every way. Also, please don't confuse lossless and lossy compression. TIFF can store uncompressed, or with lossless compression (e.g., LZW). PNG can store with lossless compression. JPEG uses lossy compression. Fidelity and quality are compromised for the sake of storage size (and thus download/upload time). There is no reason to choose uncompressed when you have lossless compression available to you (e.g. PNG).

Honestly, you shouldn't ever use TIFF if you can avoid it. It is provided in Paint.NET only as a best-faith convenience feature.