Rick Brewster

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.

The memory leak is fixed. That does not mean that Paint.NET is invincible to out-of-memory conditions (often caused by fragmented virtual address space), it just means they aren't as trivial to create. My original recommendation still stands: install a 64-bit edition Windows.

Yes, that sounds right. I never said anything about implementing it. I haven't committed to anything of any type for anyone regarding any feature at this time.

Feb 18th, 2010 update -- added info about portable Paint.NET

I checked again, and I never said the issue was fixed. Please stop nagging me.

Just get LiberKey they have a portable version. http://www.liberkey.com/en/

Yes, that's what you'll need to try next. In the crash log, look through the list of "Native modules". In general, anything in C:\WINDOWS\system32 can be ignored. Your next two targets should be Dropbox and "Symantec Endpoint Protection".

I've posted a beta build of Paint.NET v3.5.4 with a fix for this, viewtopic.php?f=46&t=33703 Please test it!

IsCancelRequested=true should be interpreted as meaning, "What you're computing right now will be discarded. So, if you'd like, stop right now."

IsCancelRequested doesn't always mean the user clicked on the Cancel button. It could just mean that the UI's data binding is still setting up, and was transitioning from default control values (e.g. zeros) to your default values. Also, Moved to Plugin Developer's Central

There is no documentation for it, nor an SDK.

I'm guessing you were using XP until recently? Vista and Win7 have a new security system and you don't have access to write to locations like C:\Program Files\* unless you "elevate" (or confirm or give permission, depending on context). This helps a LOT to make sure malicious programs can't go doing bad things (e.g. replacing system files) without your knowledge. Running everying as Administrator all the time got XP into a lot of trouble. The version of WinRAR you're using probably isn't written with this in mind; maybe you have an old version. Sarkut's work around should work too. http://en.wikipedia.org/wiki/User_Account_Control

There was a change in v3.5.3 that causes Browse to crash. Now, of course this is in code that isn't "for plugin use" but the fix is easy enough ... v3.5.4 will fix this without needing a new version of this plugin.

I'm not sure what you're supposed to do either because I can't see the error messages behind the blurring.

Moved to Troubleshooting

Actually in this case it's just a matter of it not really fitting well into Paint.NET's design. I think there's an editor out there that does, in fact, allow you to open a JPEG and it'll only recompress the portions of the image that you change. I don't remember its name. However, implementing that would be a major undertaking in Paint.NET right now. Theoretically possible, sure. But the cost:benefit ratio is sky-high.

Paint.NET simply does not inspect the orientation metadata. But as Wilson said, thankfully all it takes it a shortcut key.

Aww ...