MJW

It'd be simpler to multiply the width of the rectangle times its height instead of using a loop. What I think should work is to clear the count in PreRender, then in each Render call calculate its ROI rectangle size and add it into the count. However, I think you'll need to copy the pixels from src to dst in the Render calls. (I should know for sure if that's necessary, but off hand, I don't.) You can do the whole thing in PreRender, but it's a little more complicated, since you either have to test each pixel to see if it's selected (which is a inefficient test), or process the list of ROI rectangles.

That control can be confusing. To rotate in a negative direction around the Y axis, do one of two things: 1) Move the second slider to the right all the way to 180. The third slider will now rotate the plane in the negative direction; or, 2) Hold down the Shift key, and move center of the ball control leftward. (This will automatically move the second slider to 180.) Holding down the Shift key confines the direction of the tilt to horizontal or vertical. Because the Rotate/Zoom control is confusing, I almost always first use the ball control to tilt the plane to the general desired position, then tweak it with the sliders. I think the Rotate/Zoom control follows the standard convention for pitch/yaw/roll, or something like that.

Your question suggests you may believe the blending somehow occurs between pixels within the layer, but that's not how it works. The blending occurs between layers. For each pixel, Paint.NET starts at the lowest layer and blends it with the pixel at the same location in each successively higher layer, taking into account each layer's blend mode and opacity, along with the opacity of the pixel in the layer. A simple example: Two opaque layers, the low layer with Normal blending mode, and the upper layer with Multiply blending mode. If each layer contains an opaque pixel at the same location, the Red component of the low pixel's color is multiplied by the Red component of the upper pixel's color. Likewise for Green and Blue. The result is the blended pixel. (Note: the blend mode of the lowest layer doesn't matter, since that layer has nothing below it to blend with.) If neither TrevorOutlaw's nor my response answered you question, I think you may need need to more precisely describe what you want to do.

That seems odd to me, because I'd assume the water, parchment, paper, etc. is part of the map, not the background. Perhaps it's just how one looks at things.

There are probably quite a few simpler methods, but one way is to use my HSV Eraser plugin. To use it, you must first download and install the plugin. Then ... Run HSV Eraser (which is under the Adjustments menu, though I should move it to the Color menu). Set the Match Color to the Secondary Color (assuming the Secondary Color is at it's default of white). Set the Value Tolerance to 0.10. This method avoids having to do subsequent edge smoothing (which tends to round off sharp corners).

The data may be incorrect because you're not doing the indexing correctly. Two 8-bit Bitmap files can be functionally identical (i.e., will produce the same image) but completely different internally if the colors in the color table are in different orders. There is no right or wrong order for the color table entries, so to process an 8-bit Bitmap file, you must use the 8-bit values as indices into the color table. The color table (a property called Palette) contains an array of Colors (called Entries). The 8-bit color values are used to index into that array to fetch the ARGB color that corresponds to the value. EDIT: Let me say it in a slightly different way, that may be clearer. If the 8-bit color is, for instance, 20, that doesn't mean it's the 20th level of brightness or anything like that. It means it's the 20th color in the color table. To find out what that color is, you must index into the table.

Since the images appear the same, yet your tool shows them to be much different, I suggest that there may be a problem with your tool. Specifically, I wonder if you're property applying the the color table, or if perhaps you're incorrectly assuming the colors in the table will be arranged in some particular order. (To get the color from an 8-bit Bitmap image, you must use the 8-bit color value as an index into the color table (aka, Palette), which contains 256 32-bit colors.)

I'm not sure that's unexpected. When PDN loads an image, 8-bit or whatever, it's converted to 32-bit ARGB. When an image is saved as an 8-bit image, the 32 bit full-color image is converted, using some algorithm, into 8-bits. I don't think there's much expectation or likelihood that the saved file's hex values will match the original values. I'm a little confused by your saying the two images look the same, but later saying that B is darker than A when using you own tool. The question I have is whether the images are identical in PDN. If they are, the question is whether they're identical when viewed with some other program -- besides your own program -- such as MS Paint (or whatever is nowadays).

If I understand what you mean, you want to be able to switch to the layer from which the selected pixel came. If that's what you want, I doubt it's practical. In many cases the color of a pixel depends on more than one layer. For example, if an upper layer's pixel is semi-transparent, or if an upper layer has a Blend Mode other than Normal. I suppose the layer-switching option could be grayed out except when the sampled pixel is an opaque pixel with only transparent pixels above it. Though in some cases the feature might be useful, I'm not optimistic Rick Brewster will find it to be worth adding. It seems rather specific to the way you use layers for what you're doing.

I expect this thread has a zombie-like complexion, since it's over 13 years old. You should start a new thread instead of posting to one that's long expired. 11) Don't reply to very old threads. Also known as "reviving" or "resusitating" old/dead threads. Also called "necroposting" (eww). If there has been no discussion in a thread for, say, 3 months ... then it is dead. Do not reply to it -- pretend like it is locked. If you reply to it, then the thread will be immediately locked and your post may be deleted. Please just create a new thread if you have something to say about that subject. However, this rule does not apply to The Overflow, Tutorials, Pictorium, or Plugins sections of the forum.

The shortcut Ctrl+Shift+C will copy the merged image without first doing Select-All.

Can't say I'm happy to have now become a Paint.NET HD second-class citizen.

I don't know why the link on the entry page no longer works, but the discussion thread is here:

I'm certainly happy you were able to solve your problem. I can imagine how difficult it would be to precisely express a technical question in a non-native language. I'm a little embarrassed to have my reply marked as a solution, since I really didn't do anything to answer your question. I wish credit could be given to whomever PMed you.

At least to me, it isn't clear what you want to do. I'm not sure what you mean by a "mask" in this context. I think you need to explain more clearly or more fully. Perhaps it would help to describe the type of image you'll start with, and what you hope to end up with. Maybe you could list the steps of the ideal process to achieve your desired result.

I think that's slightly incorrect. Left or right clicking on the color wheel selects whichever one, Primary or Secondary, is the current choice in the drop-down box at the top of the Color menu. I believe it would be better if it worked like the Dropper. Or perhaps left clicking should select whichever is the current choice, while right clicking should switch the choice, and then select that color. That seems very practical, but it might be confusing. (I don't think the Dropper could work that way, because then the user would have to see the Color menu to know which was being chosen.) I think the original commenter has a good point. Maybe there could be a setting for whether the Color menu is initially expanded. Perhaps there could even be a third option of have it initially not expanded, but to automatically expand it when a color is selected with the Dropper. I nearly always want the full Color menu when I sample a color.

(Some, such as a book, have already been done since I originally posted the comment.)

I'll try to have a Tarot Card entry, but I do think that this theme, the Dog theme, and even to some degree the Milk Carton theme, lean too heavily on drawing skill. Specifically, it seems to me that while there are opportunities for using plugins to add certain effects, producing a tarot card is primarily making a rounded-corner rectangle, and then using a brush or curves to draw the rather complex tarot card art work. It doesn't seem to depend much on other Paint.NET features. That's different from, say, a regular playing card, because except for face cards, regular cards consist of very simple shapes, with a back that's generally a geometric pattern.

What really should happen, I think, is that when the edge is reached, the tool continues to move at the same speed across the canvas as it was moving, rather than going into hyperdrive. I have no idea how easy or difficult it would be to make it work that way.

Congratulations to the winners, @Pixey and @lynxster4! Though the entries were indeed few, they were certainly worthy winners. All three entries were admirably well done. Once again, I apologize for not entering. The last two themes just didn't really fit into my bag of tricks. Unfortunately, I don't think the current "dog" theme does, either. It seems to require a lot of drawing with the mouse, which isn't something I'm good at. (However, perhaps I'll come up with something.)

I can understand the problem. I think since the responses were from long-time PDN users, they assumed their answers implied there was no feathered selection, and that was why they were offering alternate methods. My original response was probably too harshly expressed. I should have just said there's no feathered selection in PDN, without the sarcastic edge.

But I need it for arbitrary colors, not jut predefined. EDIT: For some reason, right or wrong, I was thinking that you can only use constants in array initializers, not methods like ColorBgra.FromBgra(0, 1, 2, 3). Now I'm not so sure. I'll look it up tomorrow. I tend to forget those details on things I haven't used for a while. Also, even that wouldn't work out all that well for what I'm thinking about. It's a rather large array, so having each entry require such a long string would take up a lot of space. I think maybe the best thing is to just use an array of unsigned ints, convert it, element by element, to a ColorBgra array in the program, then set the int array to null and let the garbage collector handle it. Far from elegant, but it would probably work okay for my idea. Oh, and thanks for the answer to a question I probably should have thought a little more about before bothering people with. EDIT 2: Pointlessly driving this thing into the ground, I think what I was remembering with regard to initializing variables with only constants has to do with constant variables -- or something like that. Is it any wonder I have to keep a C# reference book handy when writing programs?

I probably should know this, but is there any compact way of initializing a 2D array of ColorBgra values? Like this, but with ColorBgras: int[,] = { {0, 1}, {2, 3}, (4, 5} };

No, other people offered alternative ways to achieve your desired result without a feathered selection -- as I did. Alternate methods which depend on the apparently distasteful manipulation of the object or the pixels of the image. (You actually marked your own post as the Solution?)

If I correctly understand what you're saying, you want the option of preserving the transparency; that is, not changing the pixels' alphas. That does seem like it might be useful. I think, though, that if there were such an option, there should also be the option, along with Straight and Pre-Multiplied, of only comparing RGB, ignoring alpha.