MJW

I'm going to repost this suggestion, because no one responded with either agreement or criticism when I posted it last February. The issue with DoubeSliders is significant, at least to me. Yesterday I was using my Paste From Clipboard plugin with a fairly large canvas. I noticed that with the current three-decimal-place precision of the location control, a singe click moved the pasted image more than a pixel. I immediately considered increasing the number of decimal places, but if I did, using the increment on small canvases would be frustrating, because the image would hardly move at all with each click. I often encounter this problem with plugin whose controls require fine adjustments. My original suggestion: Another, perhaps more straightforward, solution is to move by ten times the increment when the shift key is pressed, and 100 times the increment when the control key is pressed (and perhaps 1000 times the increment when both are pressed).

Unfortunately, I don't think it would help with that. If you can describe what happens in more detail (or provide an example), maybe I or someone else can figure out the cause. I suppose it could be due to the color values in the transparent pixels, depending on what plugins were used.

You should never do anything else. Not multiplying the color components by alpha when subsampling is wrong, as your previous results showed. Specifically, the color components should be multiplied by alpha and added, then the sums should be divided by the sum of the alphas (unless, of course, the alpha sum is zero). The average alpha should be computed by dividing the alpha sum by the number of subsamples. I assume that's what you're now doing. If not, try doing it that way. The problem with allowing explicit control over the RGB and alpha channels is, I think, that it adds quite a bit of complexity for something that seldom matters. I do wish the default transparent value was all zeroes, but that's somewhat a different issue. It was a while before I found out about the very useful overwrite mode.

I should have. The reason I didn't (which probably didn't make sense) is that I thought @HurricaneRL wanted exact pixel positioning, which isn't easily done with Paste from Clipboard, because the double-vector location control isn't in pixels. Now that I think about it, though, I realize that that effect may satisfy HurricaneRL's needs, and even if it doesn't, it provides a starting point for discussing what they are.

No example I post would tell you much, since the only affected pixels are transparent. When you clear a selection with Erase Selection, PDN fills the region with pixels with 0 for alpha, and (255, 255, 255) for the RGB values. Some plugins will make pixels transparent by setting alpha to 0, but leaving the RGB values unchanged. The RGB values can be anything, since if alpha is 0, the pixel will be transparent. Sometimes the RGB value matters, though. For example, when using the Maximum merge mode in the Texture Merger, it's almost always best to have the RGB of transparent canvas pixels set to 0, which represents the minimum height-map height. (Transparent pixels with RGBs of (255, 255, 255) are at the maximum height, so they will always win out in the Maximum comparison over clipboard pixels.) This plugin just sets all the transparent pixel RGBs to the same value, (0, 0, 0). This is a really boring plugin that I wrote in response to the thread Setting and maintaining RGB values for zero-alpha pixels. Most people will have no need for it, but I decided to release it for those who might.

@HurricaneRL, if you can describe what you're trying to achieve, maybe something could be done to accomplish it in a different way. How do you want to specify the location for the imported image? I assume it would be the way you currently specify the location of the Helplines. Do you always want to add the image at its full size, or do you need to scale it? Do you always want to specify the position of the imported image relative to one of its corners? Do you want the position of the imported image within the canvas to be an exact pixel location, or does it need to be to subpixels?

I don't know what Helplines/Guidelines are (epic or otherwise), but if they're any kind of snap-to feature, that probably can't be done with a plugin. Instead of assuming we know what Gimp and Photoshop do, it would be better if you described in some detail the feature you want. If it just involves drawing lines at specified locations, that could probably be done reasonably easily.

This may be helpful: Transparent to Transparent Black. (Though, as, I mentioned, I don't believe antialiasing should be affected by the RGB values of transparent pixels.)

Transparent to Transparent Black is an utterly trivial Adjustment that changes all the transparent pixels to transparent black (0, 0, 0, 0). It can sometimes be useful, particularly when using the Texture Merger. DLL, Version 1.0: TransparentToTransparentBlack.zip The code:

(For simplicity, I'll confine my answer to the cubic cases, which are by far the most common in graphics.) A Bezier curve is a single cubic polynomial whose shape is determined by the two endpoints and two control points. A spline is a chain of cubic polynomials, attached end to end, which passes through a given sequence of points. Between each two consecutive points, there's a different cubic polynomial, but the polynomials are selected so that where they meet, certain continuity conditions are met. For example, the derivatives could match, or both the first and second derivatives could match. Splines can pass through an arbitrary number of given points, while Bezier curves can pass through at most four (and if they're specified by the four points they pass through, they aren't, strictly speaking, Bezier curves.)

Transparent pixels are 255, 255, 255. I wish they were 0, 0, 0. Nevertheless, I don't think the color of transparent pixels should affect the color that results from antialiasing if the antialiasing is done properly. When computing the resultant color, the RGB components should be multiplied by alpha before being combined with the foreground color, so no matter what the transparent color, the result should be the same. I tried using the Text tool against transparent white and black, and the result seemed to be the same. How are you producing the letters, and can you provide an example?

Moving more regions makes the job more complex (as you might imagine). To do so, the first thing to do is to remove the optimization of testing the Y bounds outside the the inner X loop. With one region, that makes sense, because there's no reason to test rows of pixels that are outside the destination rectangle. With more than one region, it's far more trouble that it's worth. All the bounds-testing code should go inside the inner X loop. What should the code do? It needs to loop through all the destination rectangles to see if the pixel is inside one of them. That requires testing against both the X and the Y bounds of each rectangle. Once a rectangle that contains the current pixel is found, the pixel from the corresponding source rectangle should be fetched as CurrentPixel, and the rectangle loop exited (probably with a break statement). Exiting isn't really necessary. It could continue to search all the rectangles. With exiting, the first rectangle has priority if destination rectangles overlap; without exiting, the last has priority. Exiting is a bit more efficient. For simplicity, the source pixel at the original (X, Y) location should be loaded into CurrentPixel before entering the rectangle loop, so that if it makes it through all the destination rectangles without finding one that contains the current pixel, CurrentPixel will contain the correct value. Probably the best way to write such a plugin is to first modify the original version by moving the Y-bounds test inside the X loop (which will actually slightly simplify the code). Once that works, change the single-rectangle test to a multiple-rectangle loop. EDIT: There are plenty of variations. For instance, you could initialize a rectangleIndex variable to -1 before entering the bounds loop, and set it to the array index of the rectangle if one is found. The source pixel would then be loaded after the loop was exited. (The rectangle array would need to contain the bounds and the move-distances for each rectangle. That's pretty much true no matter how you do it.) EDIT 2: Just because I need to over-explain everything, I'll mention that for simplicity, instead of storing "move distances," it may be better to just store the source rectangle bounds in the array, then compute the srcX and srcY by adding the source bounds and subtracting the destination bounds. Saving two extra integer operations probably isn't worth the added complexity.

Perhaps this thread can be moved to Plugin Developer's Central, where it better fits. To understand how plugins work, read the tutorials listed in the first comment in the Codelab thread. Getting a pixel from an x, y location is done by assigning the source buffer value to a ColorBgra variable: ColorBgra pixel; pixel = src[x, y]; Setting a pixel is done by assigning the variable to location in the destination buffer: dst[x, y] = pixel; This is the basic CodeLab rendering code: #region UICode int Amount1=0; //[0,100]Slider 1 Description int Amount2=0; //[0,100]Slider 2 Description int Amount3=0; //[0,100]Slider 3 Description #endregion void Render(Surface dst, Surface src, Rectangle rect) { // Delete any of these lines you don't need Rectangle selection = EnvironmentParameters.GetSelection(src.Bounds).GetBoundsInt(); int CenterX = ((selection.Right - selection.Left) / 2)+selection.Left; int CenterY = ((selection.Bottom - selection.Top) / 2)+selection.Top; ColorBgra PrimaryColor = (ColorBgra)EnvironmentParameters.PrimaryColor; ColorBgra SecondaryColor = (ColorBgra)EnvironmentParameters.SecondaryColor; int BrushWidth = (int)EnvironmentParameters.BrushWidth; ColorBgra CurrentPixel; for (int y = rect.Top; y < rect.Bottom; y++) { for (int x = rect.Left; x < rect.Right; x++) { CurrentPixel = src[x,y]; // TODO: Add pixel processing code here // Access RGBA values this way, for example: // CurrentPixel.R = (byte)PrimaryColor.R; // CurrentPixel.G = (byte)PrimaryColor.G; // CurrentPixel.B = (byte)PrimaryColor.B; // CurrentPixel.A = (byte)PrimaryColor.A; dst[x,y] = CurrentPixel; } } } The thing that needs to be kept in mind is that the rendering code is called many times to render rectangles within the image. The rectangles are called Rectangles of Interest (ROIs). The pixels in the ROI represent destination pixels. You need to figure out how each destination pixel can be obtained. This sometimes complicates otherwise simple procedures. To demonstrate, I wrote a plugin to do something along the lines of what I think you're trying to achieve. The user specifies a source location, a destination location, and a size. The plugin moves a rectangle of pixels whose upper-left corner is at the source location to the rectangle at the destination location, while leaving the other pixels unchanged: // Name: Move Rectangle // Submenu: Test // Author: MJW // Title: Move Rectangle // Version: 1.0 // Desc: Move a rectangle of pixels // Keywords: // URL: // Help: #region UICode IntSliderControl Amount1 = 0; // [0,4000]Source X IntSliderControl Amount2 = 0; // [0,4000]Source Y IntSliderControl Amount3 = 50; // [0,4000]Destination X IntSliderControl Amount4 = 50; // [0,4000]Destination Y IntSliderControl Amount5 = 100; // [1,4000]Width IntSliderControl Amount6 = 100; // [1,4000]Height #endregion void Render(Surface dst, Surface src, Rectangle rect) { int dstX = Amount3; int dstY = Amount4; int moveX = Amount1 - dstX; int moveY = Amount2 - dstY; int dstEndX = dstX + Amount5; int dstEndY = dstY + Amount6; int width = src.Width; int height = src.Height; ColorBgra CurrentPixel; for (int y = rect.Top; y < rect.Bottom; y++) { if (IsCancelRequested) return; if ((y >= dstY) && (y < dstEndY)) { // The row is within the destination rectange Y bounds; check for pixels also in the X bounds. for (int x = rect.Left; x < rect.Right; x++) { if ((x >= dstX) && (x < dstEndX)) { int srcX = x + moveX; int srcY = y + moveY; if ((srcX >= 0) && (srcX < width) && (srcY >= 0) && (srcY < height)) { // Move pixel to the new rectange. CurrentPixel = src[srcX, srcY]; } else { // Source pixel is outside image. CurrentPixel = ColorBgra.Transparent; } } else { // The pixel is outside the X bounds of the destination rectangle. CurrentPixel = src[x, y]; } dst[x, y] = CurrentPixel; } } else { // The pixels are outside the Y bounds of the destination rectangle. for (int x = rect.Left; x < rect.Right; x++) { dst[x, y] = src[x, y]; } } } } The basic idea is that it goes through the pixels in the ROI. if the pixel is inside the destination rectangle, it copies the corresponding pixel from the source rectangle into the destination pixel. If the pixel is outside the destination rectangle, it copies the pixel from the same location from the source buffer. Note that for pixels inside the destination rectange, I need to test to see that the corresponding pixel in the source rectangle is inside the image. If it's not, I make it transparent.

Select the Move Selection tool from the Tool list. (It's the fourth one on the list.)

I think reflections are okay. They serve a similar function to shadows of adding an extra touch of solidity to the object, and they're a manifestation of the object, itself, not a separate object.

@LionsDragon, what I still need is information about, and examples of, the starting pattern images. If all the patterns were like the horse-head example you gave, the task would be fairly easy. If they were scans from the pages of the magazines I looked at, it would be, at least for me, prohibitively difficult. I need to understand what kind of patterns the plugin's potential users, such as you and @Santiago, expect it to handle. Before I looked at the magazines, I thought I might backtrack on my absolute assertion that I couldn't handle scanned magazine images. However, after looking at their patterns, I'm quite certain they would be too complex for me to process. The icons within the cells make it more difficult, not less. And because the cell colors aren't exactly the thread color required, a plugin couldn't rely on the color within each cell, even if it could accurately determine what it was. Also, the cells are tiny, which makes avoiding errors in locating each cell even trickier. Another problem, at least with the cross-stitching magazine, is that sometimes letter stitching was shown superimposed over the top of the cells. So I can say quite definitely that I won't be writing a plugin that takes images like the ones in the magazine, removes their icons, and substitutes its own. I will try to write a plugin if, 1) I can clearly understand the type of input pattern data I need to process, and 2) processing the input patterns is reasonably straightforward.

I happened to be at the library today, so I took a look at a couple of craft magazines. I recall the names being "Craft Ideas" and "Cross-stitching and Needlework." Their patterns already had little icons in each cell to identify the colors. The icons were a rather random assortment of numbers, letters, and symbols, such as hearts. I also noticed that sometimes the cell colors didn't exactly match the intended color. For instance, black cells were dark gray so that the icon -- which was always black -- was visible.

Those are some good suggestions, @MadJik, though I think something like reducing to 32x32 and increasing back to 320x320 works only because the original pattern was a computer image, and therefore completely predictable. If it were a photo, I think some of the cells would disappear and others would be various sizes, depending on how the pixels matched to the cells.

I sorely regret I didn't submit an entry to the Night-time SOTW contest. Once again, done in by my poor time-management skills. I really liked the theme. It's pretty much exactly what I think a SOTW theme should be: clearly defined, but allowing a wide range of interpretations.

@Santiago, the first thing I, or anyone else writing such a plugin, needs to know is the format of the input pattern images. Or perhaps I should say, formats. And it's got to be pretty clearly specified: "The cells will be between 10 and 20 pixels square . . ," etc. One thing I should make clear is that for any plugin I would write, the input pattern would have to be a computer image. No photos or scans of patterns from magazines. That would require image-processing well beyond my expertise.

@LionsDragon, one of he biggest problems from a coding point of view is knowing what sort of variations there are to the patterns. I don't want to devote the rest of my life to updating the plugin to handle some new format or another. I can see why they use the thick lines to show the the divisions of ten, though I'm not sure why they don't use lighter or darker grid-line colors every 10th line instead. Not that it matters really. I care what they do, not what I think they ought to do. If you or anyone else can describe what you like the plugin to do in more detail, and in more exact terms, it would help in writing the plugin.

@Eli, the purpose of the plugin would not be to create bead-work patterns from artwork or photos -- though that would be an interesting and useful plugin, I'm sure. The (more mundane) purpose of the proposed plugin would be to take already-existing patterns and add numeric labels to the color cells. As they are, it's often difficult from looking at the pattern to determine which of two similarly colored beads (or whatever) to use.

If the plugin uses seven-segment numbers, they would fit in a 9-pixel-wide region. In that case, they would almost fit into the 10-pixel cells. They would fit if they're allowed to abut the grid lines for the cells with 2-pixel grid lines. That might be workable, though care would need to be taken so that the color of each number contrasted with both the cell color and the grid-line color.

In that image, each cell, including the grid, is 10 pixels. That would be easy to sample at the approximate center of the cells (the cell size could be settable). I think any numbered version would need to be larger in order for the numbers to fit and be legible. Is the two-pixel grid border, with two-pixel grid lines every 10 cells a standard feature?