MJW

I'm a little confused what you mean, Pixey. As long as you have areas of non-transparency separated by areas of transparency, it should work, independent of any blending modes. Whether the result is useful or not depends on what you're trying to achieve. You might try the simple flower example I show in the original comment to get a feeling for what the plugin does. I like that blue bird picture.

I'm not sure what you mean by "the right one." I think I prefer the third one, because the colors are quite striking, but that doesn't make the others wrong.

Coincidentally, just before this thread was begun, I started a thread which suggested a feature that would, I believe, solve the problem. I have no idea whether my suggestion will be seriously considered, but I hope it is. It would be very useful, and (I believe) not especially difficult to implement.

I notice most current entries don't adhere to the rules of no labels and no background. Though I have no problem with the "no labels" rule, I wonder if the "no background" should be modified for this particular topic to allow a colored background or perhaps a simple gradient. Baseballs are close to white, so they might not be best displayed against the white background that results when the background is transparent. (Though, as the Wikipedia baseball picture illustrates, with the right shading, a baseball against a white background can still be effective.) (Also, a gentle reminder to dipstick: As attractive as the Blender-rendered baseball may be, Blender is not 100% PDN.)

From the image, it looks like it has some sort of bulit-in dithering mode. I can pretty much say that PDN will never have a native drawing mode like that. There are, however, plugins (like BoltBait's Floyd-Steinberg Dithering) that will convert images to dithered two-color versions.

Perhaps you could explain what MS Paint "black and white mode" is, and what you want to use it for. I'm probably not the only one who hasn't used MS Paint for ages, and has no idea what feature you're requesting.

I'm embarrassed to not have an entry in a topic I suggested. It wasn't for lack of trying. Just lack of successful trying. I hate it when a plan doesn't come together.

That's true, but there are a couple disadvantages: first, the curve definition is done out of the context of the other layers. Second, unless the end slopes of the splines can specified (and they currently can't be) cubic splines quite often don't do what one wants near the endpoints. The first problem -- which is very significant -- could be partly alleviated by optionally allowing the clipboard image to serve as a backdrop, so the user could copy the other layers; still, nothing beats being able to freely interact with the other layers in the standard PDN environment. EDIT: When I say "cubic splines quite often don't do what one wants near the endpoints," I'm referring specifically to splines that use "free-end" conditions, where the second derivatives at the ends are set to zero. Because the curvature goes to zero, free-end splines flatten out at the ends, which is often undesirable. There are other "automatic" choices for end conditions that might work better. Except for the problem of choosing good end conditions, cubic splines are very nice.

A feature I would find very useful is a "connected" mode for the Line/Curve Tool. When activated, the first click would specify the starting point, and all subsequent clicks would specify the endpoint of the current curve and the starting point for the next curve. The nodes for the current segment (possibly excluding the first) could be re-positioned before the next segment was created. (It would be even better if all the nodes in a continuous curve were movable, but in that case, the the begin/end nodes would need to be easily distinguished from the in-between nodes.)

What a great idea! I wish I'd thought to do that.

Congratulations to Woodsy and Pixey. I'm jealous of both their entries.

I wouldn't say ignore it. Just be aware of the limitations. It's a lot easier to make a color darker without otherwise changing it by adjusting the value then by fiddling with the RGB.

It happens because colors are stored as Red, Green, Blue, not HSV. When you enter an HSV value it's converted to RGB, then the HSV value for the RGB is displayed. For example, suppose you have a color with a very low value, so there are only 3 bits of non-black color. There aren't 360 hues that can be formed from those bit combinations, so some hue values won't be available.

As long as the text color is fully saturated (that is, it contains no white), you can use the Color Clearer plugin to clear the background. The color in your example is fully saturated, so it would work. The result will generally be better than using the Magic Wand to erase the white. If you create the text yourself, create it against a transparent background. Then there will be no white that needs removing.

You might want to try Paste Warp+.

Paste Warp+ is an enhanced version of TechnoRobbo's Paste Warp plugin. It's in the Selection submenu. The primary enhancement is the ability to move and scale the clipboard image. Paste Warp+ also supports antialiasing and a number of clipboard tiling modes. The DLL (Version 1.1.0) : Paste Warp Plus.zip The UI: The Help Menu description: Paste Warp+ distorts the clipboard image horizontally and vertically to fit the current selection. It works best with convex selections, but will often work with nonconvex selections, depending on the shape of the selection and the type of distortion. The Distortion can be set to values greater than one. This is may produce unusual effects, but is sometime useful when the image size is reduced. The Bulge and Skew controls affect the image even when the Distortion is zero. When a Bulge control is at its minimum or maximum value, the corresponding Skew control is disabled. The controls are: Clipboard Image: Specifies how pixels outside the clipboard boundaries are treated. Pixels outside the image range of the clipboard can be transparent, Clamped, Tiled, Alternately Tiled, or Brick Tiled. When Alternately Tiled is selected, the tile orientation is reversed for every other tile, so that the tiles match at the edges. The edge pixels are not repeated. When Brick Tiled is selected, every other row is offset by half the image width. The rows do not wrap from the top to the bottom. Clipboard Image Size: Increases or decreases the size of the clipboard image. Clipboard Image XY Proportion: Changes the XY proportion of the clipboard. Moving the control right increases the X size while decreasing the Y size. Moving the control left decreases the X size while increasing the Y size. Clipboard Image Offset: Moves the clipboard image relative to the selection. Clipboard Image Rotation: Specifies a counterclockwise rotation angle for the clipboard image, in degrees. Horizontal Distortion: Specifies the degree to which the image is horizontally distorted to conform to the shape of the selection. Horizontal Bulge: Specifies the degree to which the center of the image is horizontally stretched or compressed. Horizontal Skew: Specifies the degree to which the image is skewed left or right. Vertical Distortion: Specifies the degree to which the image is vertically distorted to conform to the shape of the selection. Vertical Bulge: Specifies the degree to which the center of the image is vertically stretched or compressed. Vertical Skew: Specifies the degree to which the image is skewed up or down. Antialias: Specifies that antialiasing should be used. Antialiasing will slow the effect, because many more points need to be processed. but will often significantly improve the results.. Antialias Quality: Specifies the number of samples in each direction per pixel. The total number of samples per pixel is this value squared. Note: Although Paste Warp+ uses the same distortion algorithm as TR's Paste Warp, the code is original. EDIT 1 (6/11/2018) : .Version 1.1.0. Fixed tiling crack problem. Added Bulge controls. Increased distortion range. Rearranged controls.

I would think that if there were a plugin that could copy a specified rectangle to a specified location, it could be used with ScriptLab to do what's wanted.

This is a CodeLab plugin that provides the code to scale, rotate, and offset a clipboard image. As a plugin, it's not too useful, but it might provide a starting point for writing plugins that use the clipboard. The DLL (in case you want to see what it does): Basic Clipboard Transformations.zip The code:

I would like to request that Pixey extend the deadline of the Art Nouveau to make it a two-week competition. That Mosaic comp rather surprisingly had enough entries in a week, but it's the last in quite a while to do so. Also, I've been somewhat busy, and don't know if I'll have time by Saturday to complete an entry.

Now I'll (more or less) briefly explain how it works. First I create an instance of the FloodFill class with its range set to the selection. Note that FloodFill takes the actual max X and max Y, not versions with one added. The range can be changed by calling SetRange(int xMin, int yMin, int xMax, int yMax). PdnRegion selectionRegion = EnvironmentParameters.GetSelection(src.Bounds); selection = selectionRegion.GetBoundsInt(); selLeft = selection.Left; selTop = selection.Top; selRight = selection.Right; selBottom = selection.Bottom; floodFill = new FloodFill(selLeft, selTop, selRight - 1, selBottom - 1); In the dst surface, I fill all the selected pixels with a flag color called "Unvisited" (which is transparent black) that indicates the pixel hasn't been visited. foreach (Rectangle r in selectionRectangles) { Dst.Clear(r, Unvisited); if (IsCancelRequested) return; } For each pixel in the selection rectangle, I call the FloodFill routine twice if the src pixel isn't transparent and the dst pixel is marked as Unvisited. (For clarity, I omit the gamma-correction stuff.) for (int x = selLeft; x < selRight; x++) { if (IsCancelRequested) return; if ((Src[x, y].A != 0) && (Dst[x, y] == Unvisited)) { // Get the sums of the color components. // Then compute the average color. rSum = gSum = bSum = aSum = 0.0; floodFill.Fill4(x, y, ComputeAverage); double aRecip = 1.0 / aSum; rSum = aRecip * rSum; gSum = aRecip * gSum; bSum = aRecip * bSum; averagePix = ColorBgra.FromBgr((byte)(bSum + 0.5), (byte)(gSum + 0.5), (byte)(rSum + 0.5)); // Fill the object's pixels with the average color. floodFill.Fill4(x, y, FillAverage); } Fiil4 takes three arguments: the int x,y coordinates and a delegate. The delegate takes two arguments -- the int x,y coordinates -- and returns a bool. The delegate tests the specified pixel to see if it needs to be modified. If not, it returns false; otherwise, it modifies the pixel and returns true. (Modifying the pixel should set the pixel to a condition that no longer fits the modification criteria.) The delegates are never passed coordinates outside the range set for the instance of the FloodFill class. The first call to Fill4 passes the ComputeAverage delegate: double rSum, gSum, bSum, aSum; ColorBgra averagePix; bool ComputeAverage(int x, int y) { ColorBgra srcPix = Src[x, y]; if ((srcPix.A == 0) || (Dst[x, y] != Unvisited)) return false; double alpha = srcPix.A; rSum += alpha * srcPix.R; gSum += alpha * srcPix.G; bSum += alpha * srcPix.B; aSum += alpha; Dst[x, y] = VisitedForAverage; return true; } This delegate returns false if either the src pixel is transparent or the dst pixel isn't Unvisited. Otherwise, it sums the color components into "global" variables and sets the dst pixel to VisitedForAverage (which is a somewhat random transparent color) and returns true to indicate it modified the pixel. When this fill is completed, all the pixels in the object containing the original pixel will be marked as VisitedForAverage, and the sums will be the sum of the color components for the entire object. The calling loop computes the average color, stores it in a "global" variable and calls Fill4 with the FillAverage delegate. bool FillAverage(int x, int y) { if ((Dst[x, y] != VisitedForAverage) || (Src[x, y] == VisitedForAverage)) return false; Dst[x, y] = averagePix; return true; } FillAverage tests to see if the dst pixel is set to VisitedForAverage and the src pixel is not. If not, it returns false, otherwise it sets the dst pixel to the average color and returns true. All this occurs before the main render loops are called. The main render loop looks like this: protected override void Render(Surface dst, Surface src, Rectangle rect) { int left = rect.Left, right = rect.Right, top = rect.Top, bottom = rect.Bottom; for (int y = top; y < bottom; y++) { for (int x = left; x < right; x++) { // If the destination pixel wasn't visited, it wasn't part of an object, so use the // source transparent pixel. Otherwise, ues the color in the destination pixel with // the alpha value from the source pixel. ColorBgra dstPix = dst[x, y]; ColorBgra srcPix = src[x, y]; dst[x, y] = (dstPix == Unvisited) ? src[x, y] : dstPix.NewAlpha(srcPix.A); } } } If a pixel in the selection was originally transparent, the fill routines won't be called for it, so the dst pixel will still be Unvisited. In that case, the src pixel value is stored into the dst pixel. If the dst pixel was visited, it will contain the average color of the object it's in, but with an alpha of 255. So the alpha value of the src pixel will replace it. Note: The name Fill4 refers to the fact that it fills 4-connected regions. Pixels are 4-connected if they touch on the sides. Pixels are 8-connected if they touch on the sides or the corners. 4-connected fills are much more commonly used, but 8-connected fills can also be useful. They're also trickier to write, and I don't yet have one I'm satisfied with. Note 2: The fills would be more efficient if the test-and-modify routines were hardcoded rather than delegates, but would be much less flexible. Note 3: Instead of processing the selection rectangle, I could just process the selected pixels using the same approach used to fill them with Unvisited. I just didn't think of that when I wrote it, and it shouldn't make much difference in performance, since the fill routines will never be called for those pixels. Note 4: Pixel that are modified by a floodfill are called "interior pixels"; pixels that aren't modified are called "exterior pixels." The floodfill must, of course, test all the interior pixels at least once to see that they need to be filled. It also has to test the exterior pixels connected to interior pixels at least once to see that they don't. It may retest an interior pixel to find that it's already filled. It may also retest exterior pixels. I haven't yet figured out how to prove it, but from experimentation I know that my floodfill routine never retests interior pixels unless the interior region has a hole. Exterior pixels are quite often retested. For example, a line of singe exterior pixels separating interior pixels will be tested twice -- once when the interior pixels on one side are filled, and again when the pixels on the other side are filled. EDIT: To my considerable chagrin, I realized I have to test the src pixel in FillAverage to see if it equals VisitedForAverage. I hoped to avoid testing the src pixel, but I don't see how I can. There's no flag value for VisitedForAverage that couldn't occur in a unselected pixel within the selection rectangle. If such a pixel were next to a filled pixel, the FillAverage routine would modify it when it shouldn't. I could avoid the problem by using a auxillary buffer, since the pixels outside the selection could be set to any value, rather than being required to equal the src values. EDIT 2: I changed VisitedForAverage from TransparentWhite to a more random transparent color. This is to make it less likely that an unselected pixel will match, saving an extra comparison to the source pixel. The advantage is at best marginal, but the change costs nothing.

I changed the CodeLab code so that it's simpler and doesn't require an auxiliary surface. I also modified the FloodFill code to use the C# Stack class for the stack rather than a linked list.

Because I think flood filling might be useful for other plugins, I'll add a comment explaining in more detail how I use it in this plugin. However, while I was looking at the Average Object Color code, I realized I might be able to implement it without creating an auxiliary surface. That would make it simpler, so I'm going to see if I can do that first. EDIT: Unfortunately, the auxiliary surface seems to be necessary to avoid writing the destination surface outside non-rectangular selections. EDIT 2: I figured out a better way to do it that doesn't require an auxiliary surface.

At Maximilian's request, I made a CodeLab version. If requested, I'll post the plugin DLL, but I'm not sure there's a good reason to do so. I think the code, itself, is fairly interesting in its use of the floodfill routine. I'm always a little nervous when I add complex one-time pre-rendering code to CodeLab plugins, but it seemed to work correctly. No guarantees, though! The icon: The code:

To set the transparency of a layer, use the Layers menu. Make the layer the active layer, then click the Properties icon in the lower-right side of the menu (it looks like a stylus pointing at a tag). That will bring up a Properties menu, where you can set the layer's opacity. To modify the pixel transparency in entire layer (or within a selection), you can use BoltBait's Transparency Adjustment and/or Red ochre's Alpha-threshold. BoltBait's Feather and dpy's AA's Assistant are useful for softening the edges of "objects," which are regions of non-transparent pixels surrounded by transparency. (I'm not sure if you're using multiple layers to do the edit, but if you're not, you should be. It gives much better control. Also, FurBlur will draw fur into the transparent region, but won't draw "transparent fur" into the opaque region. That makes it advantageous to have the outside region transparent rather than a different color.)

Congratulations to Pixey, Shochi, and Noop. Thanks to all those who voted, for me or otherwise (but especially for me!). Thanks to Pixey for hosting, and for choosing a topic that managed to attract sufficient entries in a singe week -- quite unusual. You're correct, Pixey, that I used the Texture Shader and Texture Merger. I'm happy that the shading was still apparent at the reduced sig size. In some cases I don't know if it is, or if I just imagine it is because I know it's there.