alexo

Same thing happened when upgrading to 3.51. Anyone?

The problem that I see is that PDN won't even let me load the plugin.

Where does the "This plugin is known to cause stability problems" message comes from anyway? Can it be overridden? I never had stability problems with that plugin.

I'm aware of that and have no plans to fix them - only the plugins in the best pack are actively maintained. StockLibrary can be achieved by simply using a folder and SubtleEffect can be achieved by using a translucent layer. I'll still consider fixing and moving Flag, though. Thank you Simon. A small request though: would you be so kind as to tell me what DLLs you consider obsolete and recommend removing? Thanks, Alex.

OS: Win XP + SP3 PDN: Paint.NET v3.5 (Final Release build 3.50.3596.41598) Screen shot: Of what? The errors are from "View plugin load errors". I'll gladly provide more info, just tell me what.

File: C:\Program Files\Paint.NET\Effects\EOEffects.dll Effect Name: PaintDotNet.Effects.PDNOctagonal Full error message: This plugin is known to cause stability problems. Please help.

Downloaded the plugin pack. PDN 3.5 says: 4 of 6 -------------- File: C:\Program Files\Paint.NET\Effects\Flags.dll Effect Name: Flags.EffectPlugin Full error message: This plugin is known to cause stability problems. 5 of 6 -------------- File: C:\Program Files\Paint.NET\Effects\StockLibrary.dll Effect Name: StockLibrary.EffectPlugin Full error message: This plugin is known to cause stability problems. 6 of 6 -------------- File: C:\Program Files\Paint.NET\Effects\SubtleEffect.dll Effect Name: EffectCaller.EffectPlugin Full error message: This plugin is incompatible with this version of Paint.NET. Please help.

Having errors loading the plugins: 1 of 6 -------------- File: C:\Program Files\Paint.NET\Effects\pyrochild.effects.common.dll Effect Name: PaintDotNet.UserControl2 Full error message: System.TypeLoadException: Could not load type 'PaintDotNet.UserControl2' from assembly 'PaintDotNet.Core, Version=3.50.3596.41599, Culture=neutral, PublicKeyToken=null'. 2 of 6 -------------- File: C:\Program Files\Paint.NET\Effects\pyrochild.effects.common.dll Effect Name: PaintDotNet.SurfaceBoxGraphicsRenderer Full error message: System.TypeLoadException: Could not load type 'PaintDotNet.SurfaceBoxGraphicsRenderer' from assembly 'PaintDotNet.Core, Version=3.50.3596.41599, Culture=neutral, PublicKeyToken=null'. Thanks, Alex.

This happened to me with all the 3.5 betas and today with the final 3.5. The installation of a new version tries to uninstall the existing one first. When the uninstall progress bar reaches about 100%, the (un)installer hangs, using a lot of CPU but seemingly doing nothing. Using the SysInternals ProcMon shows that the MSI process apparently tries to open each every registry key in existence. Killing that process allows the installation to continue.

That's an interesting idea but I was under the impression that plug-ins don't have the same access to the "rendering surface" (or however it is called) that the main program has. Or am I wrong?

Hi Illnab1024, Thanks for the explanation. So, if I understand you correctly, if one only works with images that are neither printed nor scaled up, there should not be any problem?

Hi Rick, Well, since I cannot convince you, I will accept your answer as final. It is unfortunate that you no longer provide the source code though. I could have just "customized" it to my specific need without bugging you. That is what I don't understand. You seem to feel strongly about it though, would you care to explain why is that the case? Can't argue with that. Thanks again for providing us with a great application and good luck on the final release. Best regards, Alex.

Hi Rick, Please don't get upset about this discussion. Nobody is suggesting that you're doing less than a terrific job with PDN. Please hear me out. I don't bug you that often, do I? Give me 5 minutes of your attention and keep an open mind -- it's all I ask. Bingo! Look at the image below: The right side is ClearType as rendered by MS-Word 2003, the left side is PDN 3.5 As you can see in the zoom, the colors of CT are all over the map but, and it is a very important "but" for me, the actual small text (size 16) looks much better and I can't really see the colors at all -- it looks black unless you zoom it (the bottom part of the image is zoomed 600%) My computer can't run Vista without a noticeable slowdown, so we're talking a hardware upgrade + the cost of an OS license. Windows 7 is better than Vista but it costs even more *and* there is no upgrade path from XP so I cannot just transfer a hard drive over and upgrade, I'll have to install all the applications from scratch, mess up with settings for each, etc. Very disruptive in addition to expensive. I'd rather pay you (or donate) a reasonable sum if making the grayscale filter optional will give me the same font rendering on XP as other applications have. It cannot be more than 10 minutes of work for you and I'm willing to compensate you for it. So, to summarize: I appreciate the time, effort and talent you poured into PDN, I don't doubt for a moment that you researched this extensively and arrived at an optimal solution, but i *BEG* you not to punish those that need a sub-optimal one. Thank you for your time. Best regards, Alex.

What I noticed, Rick, is that the font antialiasing of 3.5b3 seems much more aggressive than that of 3.36. It is mostly noticeable with thinner fonts in small to medium sizes. The effect is to make it seem that the strokes have "holes" in them. That raises the question, how to you anti-alias fonts in PDN? Do you use CreateFontIndirect() with the lfQuality field of the LOGFONT set to ANTIALIASED_QUALITY (4)? In that case, CLEARTYPE_QUALITY (5) or CLEARTYPE_NATURAL_QUALITY (6) may give different results. Could you make it user-configurable? Thanks, Alex.

Rick, a lot of people run Paint.NET on XP and frankly, the fonts on 3.5beta look terrible in all but the largest of sizes. Performance may have increased but the image quality suffered greatly.

I'm more interested in the other three I wonder if, due to Paint.NET being a showcase of Microsoft's .NET technology, the MS-Research people can be persuaded to contribute... Obviously I am not the person to approach them though.

There are some technologies from Microsoft Research that I'd love to see in Paint.NET (either natively or as plug-ins): [*:3vpyg5gh]GrabCut [*:3vpyg5gh]Patchworks for object removal. [*:3vpyg5gh]Blender for seamless object insertion [*:3vpyg5gh]Bayesian Color Constancy Is it feasible?

Sorry for being unclear Rick, I was talking about opening multiple images simultaneously, where each one fits in available memory individually but the lot of them does not. Thanks, Alex.

Hi Rick, Can you comment on my suggestion above? Is is doable? Is is worth doing? Thanks, Alex.

I got an "insufficient memory" error when I tried opening a large number of images. I understand that Paint.NET keeps the images in memory but there is actually a mechanism in Windows to allow an application to allocate huge amounts of virtual memory without the need of a 64-bit address space or the /3GB switch. Raymond Chen explained how to to do it in 2004 in his blog (Myth: Without /3GB a single program can't allocate more than 2GB of virtual memory). I will add that you are not even constrained by the size of your page file since CreateFileMapping can use a disk file for backing storage. Now, I am not familiar enough with .NET to speculate on how easy it will be to implement such a technique, but if it is feasible (and I really hope that it is), the number of concurrently open images will only be constrained by free disk space (assuming any single image can fit in available memory). Obviously, the trade-off will be slower switching between images but it could be made a configuration option. What do you think?