MJW

A problem I have is that I can't figure out how paste formatted text. With the previous forum software, formatted text would retain the formatting when pasted. For plugin releases, I'd like to post the already-formatted Help file RTF text into the comment, instead of having to reformat it. EDIT: Never mind. I found if I copy the formatted text from OpenOffice instead of WordPad, the formatting is retained. That may have been the same in the old forum software.

Thanks, Drew! I planned to submit an entry, but haven't had time. Too much Olympics watching, among other things. I also think the insect topic takes more time than usual. I'll do my best to get one done.

Three 50% blends won't produce the correct average. The last layer will get more weight. Specifically, the weights will be 25%, 25%, 50%.

Your strategy of essentially using a median of a number of images seems like a good one, but I don't see how it can be done within PDN. Other than by using the blend modes, which don't really do what you want to do, the only way I know to have multiple images "active" at the same time is to have one in the active layer, and one in the clipboard. For the median idea to work, you need more than just two images. I can't see any way to break a median-type operation into a series of pairwise operations, though perhaps there is. You could average together a power-of-two number of layers reasonably simply. Just average them pairwise. For example, for four layers, average layers 1 and 2; then average layers 3 and 4; then average the two averaged layers. To average two layers, set the opacity of the top layer to 50% and merge the layers. Actually, you should be able to average three layers by setting the opacity of the lower layer to 100%, the next layer to 50%, and the top layer to 33%. The same idea should work for more layers. Just set the layer opacities to 100%/n, where n is the layer number, numbering upward. For removing noise, using the mean average isn't, I would think, nearly as good as using the median.

I wasn't complaining; just explaining why I posted my congratulatory comment here and not on the competition thread.

The Impressionism SOTW thread seems to be closed, but I wanted to congratulate doughty on the stylish winning entry.

Paste Alpha is a plugin I use often. For making regions transparent, Erase Selection is a saw, while Paste Alpha is a X-Acto knife.

If you want to test if a pixel is transparent, do what toe_head2001 suggests: only test if alpha is 0. It's the correct thing to do, and it's easier to boot. I'll mention in passing that you can directly compare colors, such as: if (CurrentPixel != ColorBgra.TransparentBlack) { ....do something } That would be an easier way to do what you did above, but it's not what you should do to test for transparency. EDIT: I should say it's an easier way to do what you seem to want to do. I think you mean to have: if (currentPixel.R != 0 || currentPixel.B != 0 || currentPixel.G != 0 || currentPixel.A != 0) The way it is, it will skip doing something if any of the color components is zero.

For textured text on a transparent background, I suggest using BoltBait's Paste Alpha plugin. Make the text black on a white background. Copy the text layer to the clipboard. Switch to the texture layer. Run Effects>Object>Paste Alpha, checking the Invert Calculation option. There are several variations, such as: Make the text black (or any other opaque color) on a transparent background. Copy the text layer to the clipboard. Switch to the texture layer. Run Effects>Object>Paste Alpha, with the Alpha Source set to Clipboard alpha.

Though you should definitely start out with a transparent background, if you have, for instance, black text on a white background, you can erase the white background with the Color Clearer plugin. That won't work for all combinations of text and background colors, because it might make the text partially transparent, but it works for most common combinations, such as white on black or black on white.

I don't care for it at all. Everything seems so large and spread out. So little fits on one screen's worth. Currently, it's like reading a large-print book. I'd prefer fewer blank areas, particularly fewer blank-line separators. For example, topic lists shouldn't be separated by blank lines.The bolded, blue-colored heading links provide sufficient separation. While the line separations may marginally increase readability, the inconvenience of the extra scrolling isn't worth it.

So you only want to compress them in Y, not also in X? How would you use it? Is each nameplate in a separate image, and you want to apply the plugin to the whole image, or are there several nameplates in a single image? If there are several, do you intend to make a selection around each nameplates, or is the plugin supposed to locate the individual nameplates and resize each one?

I'm still not clear on what you want to achieve. A before and after example might help.

Though I'm not sure what the potential plugin is supposed to do, I'll offer two pieces of advice anyway. First, the xfactor in BoltBait's comment is generally the reciprocal of the scaling factor (i.e., 1.0 / xscale). That's because you're not trying to transform a source pixlel into a destination pixel; you're trying to calculate which source pixel transforms into the given destination pixel. Second, unless you want the scaling to be relative to the upper-left corner, you need to include an offset: wrk[x, y] = src.GetBilinearSample(x * xfactor + xoffset, y * yfactor + yoffset); The offsets can be precomputed as follows: double xoffset = (1.0 - xfactor) * xcenter; double yoffset = (1.0 - yfactor) * ycenter; (xcenter, ycenter) is the point about which the expansion or contraction occurs.

All PDN. Plugin credits include (but are not limited to), Red ochre's ArtyThing, MKT's Shape3D, pyrochild's Grid Warp, TR's Radial Extruder, Michael Vinther's Laplacian Pyramid Filter, Kris Vandermotten's Drop Shadow, and my Texture Shader.

If you have a scanner, you could just scan it, then add a new layer on which to type the number. You could then print the text layer. To preserve the size, you'd have to take into account all the DPI stuff so the printed resolution matched the scanner resolution, but I expect (or hope) it wouldn't be too difficult. EDIT: Something not addressed, as far as I could see, in the DPI thread is that normally when I print pictures, they're automatically resized to fill up the paper size (which is what I usually prefer). I assume that the way to avoid that and make the printing match the picture's DPI setting is to uncheck "Fit picture to frame," though I've never actually tried it.

Assuming I correctly understand what you want to accomplish, one thing you could do is set PDN to show the cursor position in centimeters, using View>Centimeters. Then set the tool to Pencil using Tool>Pencil. Move the cursor around until the position display in the lower-right side of PDN shows a position as close as possible to the measured location, and click the mouse to make a dot. You can use the marks to place the cursor and type the numbers using the Text tool. You could also go straight to typing the numbers, though that seems a bit less precise. Not exactly elegant, but unless you have to do it many times, it's probably easier than coming up with an elegant solution. EDIT: For printing, you might want to read the thread on image DPI. I admit I haven't more than skimmed it, myself. (The resize resolution will be be in metric units if Centimeters are being used.)

You actually don't have to select the entire canvas. The Ctrl+Shift+C keyboard shortcut works even if the canvas isn't selected, though the menu version doesn't.

That's an interesting idea for a plugin, and perhaps I'll write one that does that, but it would most likely be a separate plugin, since the the way it worked would need to be quite different than simply summing the weighted RGB components.

You're certainly welcome. One more thing. If you have a burning desire to handle transparency, I believe the following might work: Rectangle[] selectionRectangles = EnvironmentParameters.GetSelection(src.Bounds).GetRegionScansInt(); totalCount = 0; foreach (Rectangle r in selectionRectangles) for (int y = r.Top; y < r.Bottom; y++) for (int x = r.Left; x < r.Right; x++) { double alpha = src[x, y].A probabilities[getGrayscaleValue(src[x, y])] += alpha; totalCount += alpha; } I'm not completely sure doing that that makes sense, though. (You could, of course, just compute the histogram, then afterward get the total count by summing the histogram entries in a separate loop.)

If you ignore the problem of non-rectangular selections, then the only problem with the code is that, for(int i=0; i<height; i++) for(int j=0; j<width; j++) probabilities[getGrayscaleValue(src[j, i])] += 1/nbPixel; should be something like, for(int i=selection.Top; i<selection.Bottom; i++) for(int j=selection.Left; j<selection.Right; j++) probabilities[getGrayscaleValue(src[j, i])] += 1/nbPixel; However, I believe the code I gave (which I didn't come up with myself, but swiped from someone else) handles all selections correctly, and isn't overly complex. As far as i know, it's the best way to iterate over the selected pixels. Rectangle[] selectionRectangles = EnvironmentParameters.GetSelection(src.Bounds).GetRegionScansInt(); totalCount = 0; foreach (Rectangle r in selectionRectangles) { totalCount += r.Width * r.Height; for (int y = r.Top; y < r.Bottom; y++) for (int x = r.Left; x < r.Right; x++) probabilities[getGrayscaleValue(src[x, y])] += 1; } (Disclaimer: I haven't tested the above code, so there could possibly be errors, but it should be close.)

It will work as far as generally producing a reasonable-looking result, but it won't be the correct result. If you select a rectangle in the center of the window, the threshold value will be based on the pixels in the same-sized rectangle in the upper-left corner. And even if the offset problem is corrected, if you select a circular selection, the threshold will be based on the pixels in the bounding rectangle. There's no possible way any sort of built-in selection management, by the plugin API or CodeLab, can make the threshold depend on the correct pixels if the plugin's computation is done using the wrong pixels.

I'd be happy to translate the pseudo-code into C# if you'd prefer not to do it yourself. I could either post it here or PM it to you.

I found some pseudo-code (page 160) that seems better suited to writing a version that handles the selection correctly. There's also a C++ version that can be downloaded, though I think it might be easier to just translate the pseudo-code. This version just adds one to the histogram entry instead of some value that requires knowing the total pixels before computing the histogram. Therefore, the total can be computed while computing the histogram. (The pseudo-code contains some stuff about making sure there's only one color channel and using a manual threshold. I'm not sure why that was included in pseudo-code which, to me, should show the algorithm without any implementation-specific fluff.)

I now see what you're saying. I'm not quite sure why there's difference, since I'd expect the threshold to be computed over the same pixels. In any case, the way the plugin handles selections is wrong, so that should be fixed. My philosophy has always been that if there's a bug that might potentally cause the problem, fix the bug, and if it fixes the problem, don't spend too much time figuring out exactly why it did. (Though I'm not always successful at suppressing my curiosity.)