MJW

Yes. The top layer should have the edge trimmed back to eliminate all of the background pixels, or the pixels that are a mixture of background and foreground (wolf fur). The purpose of this layer is to prevent erasing any foreground pixels that happen to have the background color. The lower layer should include the entire image, or at least all the edge pixels. You could erase most of the background away from the edge, but I find it easier to leave the entire background. (What I refer to as the lower layer is actually the middle layer if you add a constant-colored contrasting background as the lowest layer.) You then use the HSV Eraser, or something similar, to erase the background, leaving the edge. If there are any remaining pixels away from the edge, they can easily be erased using the Eraser tool. It's much more important to get a good-looking edge than to erase every background pixel. Ideally, the edge will be smooth, but for the wolf picture, it may still be a little ragged. (It would be much easier to get a smooth edge if the background color were more distinct from the wolf's color.) Various tricks can be used to smooth the edge. I first used the Zoom Blur since it blurs outward from a central point, which is sort of the way the fur grows. Then I applied the AA's Assistant and BoltBait's Feather. These are for me the go-to plugins for edge smoothing. I could probably do a better job then I did. I'm not too pleased with the darkish line along the top of the wolf's head. EDIT: To smooth the edge, you might also try using Red ochre's FurBlur plugin as Cc4FuzzyHuggles suggested. That seems like an excellent idea.

Another useful background-removal plugin I'll mention (because I wrote it) is the HSV Eraser. It may be a little difficult to use, but it allows considerable control over which pixels get erased, and the "Portion of Non-Erased Color to Preserve" feature allows "soft" removal of edge pixels for less ragged results. Besides the explanations in the HSV Eraser thread, I show how it can be used to remove a background while leaving hair in a comment in a thread on the subject. The wolf photo is actually fairly difficult becuase the dark gray fur is similar to the black background. The following version of the wolf photo was produced by the ideas mentioned in the hair comment, followed by a few steps to soften the edge. Keep in mind that the upper layer contains the non-edge part of the image, to fill in any non-edge pixels that might be erased by the HSV Eraser, and the lower layer contains the edge pixels. Before I merged the layers I applied the following steps to the lower layer. Effects>Blur>Zoom Blur: Zoom Amount: 2 Center: 0.07, 0.51 Effects>Object>AA's Assistant Soften the edges: Checked Gamma: 1.42 Offset: 1.00 Effects>Object>Feather Object Feather Radius: 2 I find Zoom Blur is often a useful trick for softening the edges of fur.

I decided to delete my original comment. Please pretend it doesn't exist. Or if anyone with the power to delete posts wishes to delete it, please do so.

Shutterstock has the original version of the photo with a grassy background. If you click Preview in the lower-right corner you will get a high quality version with a very faint watermark that can be cut-and-pasted into PDN. You can use it to experiment with coloring. I doubt you should post that version, even modified; it might be a copyright violation. Perhaps posting isolated areas, such as the eye region, would be okay.

Marilynx, the photo has obviously had the original background replaced with a black background. I wonder if perhaps the same image can be purchased with a transparent background. If it can, then you probably don't need to worry about that aspect of the process. You could just figure out whether you can to do the color-changing part. If that works out, you could decide whether to purchase the hi-res image. I don't know much about stock photo companies, but I would think most people who purchased the image would prefer to get one with a transparent background, rather than having to reinvent the wheel by re-removing it.

Marilynx, can you perhaps post the original photo, before the background was removed? I think some here might be able to suggest how the background can be removed more cleanly. Background removal is often difficult, and the best approach depends a lot on the particular picture.

I'm pleasantly surprised. I figured your comment was just a drive-by semi-spam. I commend you for your courteous apology.

It is in the mini tutorial thread; that's where I first spotted it. This thread may be "outdated," but the method isn't. The linked picture is, indeed, what it produces. I'll probably use the Black and White adjustment followed by the Threshold plugin or the Curves adjustment in place of multiple applications of Auto Level, because it seems a bit more direct. The method can be used with my Texture Shader plugin in place of Emboss to produce a variety of results. The reason I've wanted this type of texture is to produce something resembling pebbled leather.

Thanks yellowman for this method. That's a texture I've tried to achieve but could never quite get right.

Why should I expect the next available layer to be the layer I'd want activated? As I understand it, the idea behind this "feature" is to not confuse users if they try to modify an invisible layer, and don't see any change. So it substitutes the user (sometimes) seeing the change, only it's probably on a different layer than intended. At least in the first case there's immediately an indication something is wrong. As far as labeling every layer, I find having to label every temporary layer distracting, and would much rather check by toggling. Everyone has his or her own way of working, I suppose.

modtyrant, I dislike that, too, and have complained about it before. It's not the "extra seconds to activate the layer," it's the fact that it's confusing and regularly results in me modifying the wrong layer. Toggling a layer off and back on is often how I determine whether a layer is the layer I think it is. Of course, I could label every layer, but when I'm working, I often have a number of temporary layers, and I don't like to interrupt what I'm doing to add labels. And I still maintain switching to some essentially random active layer achieves no useful objective. There's no reason to expect it will be a layer I'd like to activate.

One way to add texture is to use my Texture Shader plugin. I generated a cloth-like texture by the following steps. A grid, using BoltBait's Grid/Checkerboard plugin, with spacing 5 and line width 1. A Gaussian blur of 1. Pyrochild's Stitch plugin, with everything default, except a distance of 1. The result was: I copied a tartan image to the clipboard, and used Texture Shader to produce: EDIT: Another idea that seems to work well to produce the cloth texture is to start with a checkerboard in place of a grid. Also, following the Stitch step, adding a bit of noise (with Color Saturation set to 0) and/or applying the Frosted Glass effect seems to give good results. EDIT 2: Thanks for the positive response to my comment! I originally neglected to write down the Texture Shader settings, so I thought I'd add them. Better late than never. Mapping Method: Surface Offset 1 (default) Texture Height Scale: 5.00 Texture Displacement Scale: 1.00 (default) Intensity Increases with Height: Checked (default) Use Alpha from Texture: Unchecked (default) Ambient Light Color: 0, 0, 0 Directional Light Color: 255, 255, 255 Directional Light Direction: 0, -135, 45 (from upper-left) Directional Light Intensity: 2.00 Apply Surface Color to Highlight: Unchecked (default) Specularity: 0.35 Specular Concentration: 8 (default) Antialias: Unchecked (default) These are not necessarily the best values, and may not be exactly what I originally used.

If you display the image in your own form, then getting the pixel coordinate where the mouse is pointing is the usual mouse-event processing, followed by whatever coordinate adjustments are necessary to account for scaling and scrolling. I suspect from your question, though, that you're asking how to get the mouse position relative to the image in the main PDN form. As far as I know, there's no way to do that, though it might be nice if there were. EDIT: Also, this question would probably be better posted to Plugin Developer's Central instead of Paint.NET Discussion & Questions.

Thank you, BoltBait. Don't worry about offending me; I said my knowledge of DLLs is rudimentary, and that wasn't false modesty. I'll make the little project I'm working on function with separate DLLs just to learn how it's done, but I probably won't use that method as the ultimate solution. I doubt the versioning problems are worth it compared to the inelegant but simpler solution of including the utility routine's source file in each project the uses it.

Too bad. I was hoping .NET was the cure to DLL Hell, not another level.

Adding the little question-mark Help button at the top of the window's frame is done a bit differently than adding a standard button. Something like: form.HelpButton = true; form.HelpButtonClicked += new System.ComponentModel.CancelEventHandler(HelpButtonClicked); The event handler is standard, except it must cancel the Help event. public void HelpButtonClicked(Object sender, System.ComponentModel.CancelEventArgs e) { e.Cancel = true; System.Windows.Forms.MessageBox.Show("This is the help text"); }

Thank you very much, Ego Eram Reputo. That's exactly what it is. I guess the reason I haven't seen the OnCustomizeConfigUIWindowProperties routine before in compiled CodeLab source is that in the past, before the blank header comments were automatically added in CodeLab, I just specified the Name and let it be inherited as the Title. In that case, prior to the Help menu stuff, no code for OnCustomizeConfigUIWindowProperties was generated. Eliminating the assignment didn't change the results for me, since the Title matched the Name in my plugin. The real question I had was whether that assignment was somehow tied into the Help menu or was something unrelated.

There wouldn't be a dual boot mode. Starting PDN would always read the index file. A user who wanted to add a plugin would start PDN and would then select Add Plugin, perhaps under the File menu, or perhaps as one of the icons in the upper-right corner. That would either just cause the index file to be regenerated, or it could start an Add Plugin dialog. The advantage to the dialog version is that it could allow the user to browse for the plugin, and if it weren't already in the Effects directory, it could copy it there. Then it would regenerate the index file. Plugins aren't normally in the Effects directory, so that would replace one step with another one; but the new step would be better integrated into PDN. The dialog would also allow the index file to be rebuilt without adding a plugin, in case the user wanted to delete plugins. Or it could have a separate delete feature. If PDN tried to run a plugin that was no longer there, it could ask the user if the index file should be regenerated. Adding plugins is not currently an operation that happens without some user knowledge and effort, so requiring an Add Plugin operation wouldn't be a big deal. EDIT: I don't know if it's possible to overwrite a plugin file if the plugin's already been loaded. There's that annoying business of the File-in-use error that occurs when trying to replace a plugin file while PDN is running. If that's not possible, the Add Plugin dialog might not be the best way to do it, and just regenerating the index file might be better. (Assuming the whole idea isn't impossible or impractical.)

Recently there was a bit of discussion about how slowly PDN starts when there are lots of plugins. I thought of a modification that might help, though I'm not sure it's even possible. Instead of searching through the plugins each time PDN is started to get the plugin info for the menus, PDN could have a special Add Plugin mode that would search through the plugins and store the information in a file. At start-up PDN could load the file, which would, I think, reduce startup time for those with a lot of plugins. Adding plugins is a much rarer event than starting PDN, so I think requiring a bit of extra effort when they're added would be worthwhile in order to speed startup.

PDN is compatible in the sense that graphic tablets can be used in place of a mouse, but sadly, PDN doesn't support pen pressure (which I assume is probably what you're asking about). Support for pen pressure is on the list of features that shouldn't be requested, since PDN developer Rick Brewster already knows it's wanted. (Just in case you might be tempted to start a thread requesting it.)

In regard to versioning, I thought .NET was supposed to have something to deal with DLL version problems. If it does, and if someone can briefly explain it, I would certainly appreciate it. The idea of having separate DLLs for the utilities, loaded at runtime, sounds less bad now that I how how difficult it is to link DLLs at build time.

Thanks, BoltBait. It sure seems difficult for something I thought would be easy!

That's exactly what I don't want to do. I don't want the plugin to rely on another DLL; I want to have the project produce a DLL that takes the plugin routines and the utility routines (which are in a DLL) and produce a single DLL that contains them both. The combined DLL would be the plugin. EDIT: The idea is that I have various utility routines that may be used in a number of plugins. Instead of having to include them as part of each plugin project, I want to build them once and have them linked into the plugins. It seem like a very basic and useful thing to do.

That may not be clear, but let me try to explain. I'm writing a Visual Studio plugin. One of the routines seemed to be generally useful, so I decided to make it a separate project, so I could use it with other plugins. I made the utility project, which, of course, builds a DLL. I then made a plugin project whose VS "solution" includes both the plugin and the utility project. The plugin project depends on the utility project. Both projects build correctly, but when PDN tries to run the plugin, I get an error saying it can't load the utility DLL. I suppose since it's called a Dynamically Linked Library, I should have expected that, but my understanding of how all that works is rudimentary. My question is whether there's an easy way to make the project produce a DLL that contains both the plugin routines and the utility routines (from the utility DLL), so it can be called as a plugin from PDN.

Another question: I believe I know how the Help menu is enabled in IndirectUI plugins, but I was wondering if it could also be enabled in non-IndirectUI plugins, and if so, how. The statements in IndirectUI are: protected override void OnCustomizeConfigUIWindowProperties(PropertyCollection props) { props[ControlInfoPropertyNames.WindowTitle].Value = "HSV Eraser"; props[ControlInfoPropertyNames.WindowHelpContentType].Value = WindowHelpContentType.CustomViaCallback; props[ControlInfoPropertyNames.WindowHelpContent].Value = helpText; base.OnCustomizeConfigUIWindowProperties(props); } I don't really understand what the ControlInfoPropertyNames stuff does, but I know it's defined as part of IndirectUI, so I'm not sure what the equivalent thing is for non-IndirectUI plugins. EDIT: On second thought, I don't think this even makes sense to ask, since the a non-IndirectUI plugin can enable the little question mark, and can display a Help Menu the same way it can display any other dialog. Since I've yet to write a non-IndirectUI plugin, I tent to forget such things.