MJW

All PDN (except the Chat Noir image from the poster). The sign font is Las Enter (personal use) by Måns Grebäck, downloaded from dafont.com. The brick wall is based on Welshblue's fabulous tutorial, with the Texture Shader used for some steps. The random variation of the brick colors was done with pyrochild's pixelate+, along with my Offset Alternating Stripes. (And I'm actually very fond of dogs, even though they do sometimes drool.) EDIT: Applied Ed Harvey's Vibrance plugin, which improves the sign, and also seems to give the image a little more "nighttime" feeling.

I was wrong about there being a bug for -90°. It works exactly as it's supposed to, just not how I expected. When rotated -90°, the leftmost column is differently shifted than the second column. I thought that was an error, but it's not. For that rotation, the leftmost column is x=0, so it should be an odd stripe (since the stripes are numbered from 1), while the next column is x=-1, which is the last column of an even stripe. The Phase control can be used the shift the starting point left.

I think there's a place for both. I've often used AA's Assistant to intentionally erode an object's edge, but at other times that behavior is a detriment.

PDN does not do batch processing. For suggestions for some programs that do, you might check here. Converting rectangles to squares seems non-trivial, unless you're willing to just crop equally on each side of the the longer dimension.

I was curious about how Red ochre and others got it to compile. I'm sort of glad it was a strange error; I was worried it was something completely obvious, and I looked like a fool.

Thanks, BoltBait!

Whatever it is, when I cut and paste it into CodeLab, I get four unclosed-parentheses errors. I'll untangle what this horribly formatted code is doing once I have a version that compiles.

Perhaps what to do is obvious, and I'm just being dense, but I can't compile the code under CodeLab because of lines like: if((x>selection.Left) && (x { Is it supposed to be: if((x>selection.Left) && (x<selection.Right)) That seems most likely, but there are other possibilities.

That's certainly impressive, Eli!

To my considerable annoyance, I found another bug. With a -90° angle, the stripes are shifted half a pixel right. As soon as have time to figure out the best way to fix it, I will. EDIT: Actually, it was a full pixel from what I expected, not half a pixel, but as I explain in a later comment, it isn't a bug.

If I may be so bold as to offer a suggestion, for the Eve Torres photo, you might experiment with two effects. The first is the built-in Effects>Blurs>Surface Blur, and the second is Michael Vinther's intriguing plugin, Effects>Photo>Laplacian pyramid filter. Both can be used to add a more digitally-painted look to photos, which I think would help blend the photo with the drawn image. The Laplacian pyramid filter is usually used to enhance details, but for a digital look, it's used to smooth the details. It often works well to follow up with the built-in Effects>Photo>Sharpen. There's also a tutorial by WelshBlue on how to Get the Digitally Painted Look.

I probably would, because I don't think 45° is the best default. On the other hand, I may be looking at the plugin with my original purpose in mind, which was to offset horizontal stripes, with the angle control just added as a bonus. Perhaps to others, 45° is as logical a default as any. It's up to you. Either would be perfectly usable.

The double slider is, I think, the best solution. A double slider isn't as elegant as an angle control, but isn't functionally much worse. I'm very happy BoltBait eliminated the old 45° restriction, which really reduced the usefulness of angle controls.

A very imaginative use of the plugin, Eli!

Thanks, Maximilian! I'll add a link in my original comment. Did you replace the angle control with a double or integer slider, or did you use the angle control with the 45° default?

I believe I've fixed the bug. I also discovered and fixed a multi-threading bug caused by moving a line of code without deleting the original line.

lynxster4, off hand, I don't know what causes that, but I'm sure it can be fixed. I'll look into it. I suspect there are cases where the line-number calculation produces a negative value prior to integer truncation. EDIT: I'm almost certain that's the problem. I'll try to fix it later tonight.

Here is the plugin you've been waiting for!!! Just kidding. This is a plugin I developed for a specific purpose, that I decided to release in case anyone has a use for it. As the Help menu says: Offset Alternating Stripes offsets alternating stripes of pixels selected distances. Stripe Width is the width of the stripes in pixels. Odd Offset is the number of pixels to offset the first stripe and all other odd numbered stripes. Even Offset is the number of pixels to offset the second stripe and all other even numbered stripes. Stripe Phase moves the point at which the first stripe begins. Stripe Angle rotates the direction of the stripes. Edge Behavior specifies how to handle points that are shifted beyond the edge of the image. The options are None, Wrap, or Clamp. Quality specifies the amount of antialiasing to use. A value of one disables antialiasing. Higher values increase the number of samples per pixel. Generally, no antialiasing is needed when the Width and Offsets are integer values. Here is the user interface: Here is an example of the plugin applied to an image: Here is the CodeLab source: Hidden Content: // Name: Offset Alternating Stripes // Submenu: Distort // Author: MJW // Title: Offset Alternating Stripes // Version: 1.0.* // Desc: Offsets alternating stripes of a selected width by specified amounts // Keywords: offset alternating stripes // URL: // Help: #region UICode DoubleSliderControl Amount1 = 20; // [1,1000] Stripe Width DoubleSliderControl Amount2 = 0; // [-1000,1000] Odd Stripe Offset DoubleSliderControl Amount3 = 20; // [-1000,1000] Even Stripe Offset DoubleSliderControl Amount4 = 0.0; // [-0.5,0.5] Stripe Phase AngleControl Amount5 = 0; // [-180,180] Stripe Angle RadioButtonControl Amount6 = 0; // [1] Edge Behavior|None|Wrap|Clamp IntSliderControl Amount7 = 1; // [1,5] Quality #endregion Surface Src; int edgeBehavior; float Syx, Syy, Syw; float evenX, evenY, oddX, oddY; void Render(Surface dst, Surface src, Rectangle rect) { Src = src; bool antialias = (Amount7 != 1); if (antialias) SetupForSubpixels(Amount7, Amount7); edgeBehavior = Amount6; float width = (float)Amount1; double ang = (Math.PI / 180.0) * Amount5; float Mxx = (float)Math.Cos(ang); float Myx = (float)Math.Sin(ang); float Mxy = -Myx; float Myy = Mxx; // Set up the offset distances. I tend to think of the initial line is even, // but then I can't really call it the first line. oddX = Mxx * (float)Amount2; oddY = Mxy * (float)Amount2; evenX = Mxx * (float)Amount3; evenY = Mxy * (float)Amount3; // Calculate the values used to calculate the stripe number. Only the low bit of the // result matters. It's used to determine if it's and odd or even stripe. float widthRecip = 1.0f / width; Syx = widthRecip * Myx; Syy = widthRecip * Myy; // Calculate the offset. Include the phase. Add a large number to always make // the result positive. Use an odd number so the first line is odd. Add half the // width-scaling value for rounding. Syw = (float)Amount4 + 40001.0f + 0.5f * widthRecip; for (int y = rect.Top; y < rect.Bottom; y++) { if (IsCancelRequested) return; float fy = (float)y; for (int x = rect.Left; x < rect.Right; x++) { float fx = (float)x; if (!antialias) dst[x, y] = GetTransformedPixel(fx, fy); else dst[x, y] = GetTransformedPixelAA(fx, fy); } } } ColorBgra GetTransformedPixel(float fx, float fy) { // Get the rotated, scaled, and offset Y distance as an integer stripe number. int dy = (int)(Syx * fx + Syy * fy + Syw); if ((dy & 1) == 0) { fx -= evenX; fy -= evenY; } else { fx -= oddX; fy -= oddY; } if (edgeBehavior == 0) return Src.GetBilinearSample(fx, fy); else if (edgeBehavior == 1) return Src.GetBilinearSampleWrapped(fx, fy); else return Src.GetBilinearSampleClamped(fx, fy); } ColorBgra GetTransformedPixelAA(float fx, float fy) { int b = 0, g = 0, r = 0, a = 0; fy += ssYStart; float bx = fx + ssXStart; for (int iy = 0; iy < ssYSamples; iy++) { fx = bx; for (int ix = 0; ix < ssXSamples; ix++) { ColorBgra pixel = GetTransformedPixel(fx, fy); int alpha = pixel.A; if (alpha != 0) { b += alpha * pixel.B; g += alpha * pixel.G; r += alpha * pixel.R; a += alpha; } fx += ssXStep; } fy += ssYStep; } if (a == 0) { return ColorBgra.Transparent; } else { // Compute the (rounded) averages. int twiceA = a << 1; b = ((b << 1) + a) / twiceA; g = ((g << 1) + a) / twiceA; r = ((r << 1) + a) / twiceA; a = (twiceA + ssSamples) / ssTwiceSamples; return ColorBgra.FromBgra((byte)b, (byte)g, (byte)r, (byte)a); } } int ssXSamples, ssYSamples, ssSamples, ssTwiceSamples; float ssXStart, ssYStart, ssXStep, ssYStep; void SetupForSubpixels(int xSamples, int ySamples) { ssXSamples = xSamples; ssYSamples = ySamples; ssSamples = xSamples * ySamples; ssTwiceSamples = ssSamples << 1; ssXStep = 1.0f / (float)xSamples; ssYStep = 1.0f / (float)ySamples; ssXStart = -0.5f * (1.0f - ssXStep); ssYStart = -0.5f * (1.0f - ssYStep); } Here is the plugin: OffsetAlternatingStripes.zip Maximilian has a 3.5.11 build. EDIT: Fixed double-stripe-for-negative-angles bug, and a multi-thread bug caused be forgetting to delete a line of code.

I while ago, I suggested some ideas for making a stamp looked roughed up. They might be combined with the cloud idea, if you want to make the paint look scraped off and chipped. Cc4FuzzyHuggles also had some suggestions on the same thread. EDIT: I realized the method may not work directly, but will with a fairly easy modification. Instead of adding the noise layer to the underlying layer, what you'll probably want to do is use BoltBait's Paste Alpha plugin to paste the alpha into the text, before applying the text to the surface image. Assuming you're starting with text (which may already be colored) on a transparent background: 1) Duplicate the Text layer. 2) Apply BoltBait's Effects>Object>Switch Alpha to Gray. (You should get black text on a white background.) 3) Follow the instructions for adding noise to the stamp (including using Additive blend mode), but don't Flatten as the last step. 4) Use Merge Layer Down to merge the noise layer with the black-and-white text layer. 5) Use Edit>Copy (or Ctrl+C) to copy the just-merged layer. 6) Switch to the original Text layer, and use Effects>Object>Paste Alpha to paste the modified alphas into the layer. Select the "Invert calculation" option. 7) You can now delete the black-and-white text layer. (You could also delete it after step 5.) After step 3, before copying the black-and-white text, may be a good time to use the Paintbrush tool to add some edge chips. You might go with something more angular than the round chips on the stamp example. The same alpha-modification idea can also be used to modulate the text transparency with cloud noise, or other types of noise. The combination of using the black-and-white text layer with the Additive noise layer means only the text will be modified by any added noise. One more observation: There are hundreds of PDN built-in effects and plugins to manipulate color; far fewer to manipulate transparency. Therefore, if you want to alter transparency, you'll have many more options if you convert alpha to gray, modify the gray image, then paste it back into alpha.

I'm obviously confused, but I can't quite understand the relationship between the integer Value property and the fact that if the increment for a two-place slider is set to 0.0025, the counter will increment every fourth click. That would seem to suggest that sometimes the counter is updated from the Value property, and other times it isn't. Which could, of course, be part of the problem.

Does the slider keep the value as an integer? That seems at odds with its behavior. If I set the increment of a two-place double slider to 0.0025, it will increment the number display once for every four clicks. That's not how I would expect it to behave if it were scaled to an integer based on the precision. I believe the internal format is decimal, which is base-10 floating point, and that internally, the UpDown control's behavior doesn't depend on the precision. The effect of having a very slightly too small value should be invisible, since the control displays a rounded version of its internal value. I still lean toward the hypothesis that in the click event handling, PDN reads the value out of the UpDown control, then writes a modified version back in. For some reason, when the number is within the sticking range, the value written back is less than or equal to the pre-incremented value. It sticks (according to this conjecture) because the event processing undoes the UpDown counter's increment. My guess is that reading and writing the control is associated with slider synchronization.

From Forbes Magazine: Adobe scientist Dov Isaacs clarifies: On behalf of Adobe Systems Incorporated … EDIT: I will say, Adobe can hardly blame people for being confused by the way they handled this.

Congratulations to SiBorg for a most deserving win!

The following trick seems to prevent the problem for values from 0.0 to 100.0. I don't like it though, and hope the bug is fixed. (And I believe it is a bug -- very likely in PDN -- not some you've-just-got-to-live-with-it floating-point precision limitation.) const double IncAdj = 1.00000000001; // Adjustment to attempt to cure a problem when the double slider increments. protected override ControlInfo OnCreateConfigUI(PropertyCollection props) { ControlInfo configUI = CreateDefaultConfigUI(props); configUI.SetPropertyControlValue(PropertyNames.TexHeightScale, ControlInfoPropertyNames.DisplayName, "Texture Height Scale"); configUI.SetPropertyControlValue(PropertyNames.TexHeightScale, ControlInfoPropertyNames.SliderLargeChange, IncAdj * 0.25); configUI.SetPropertyControlValue(PropertyNames.TexHeightScale, ControlInfoPropertyNames.SliderSmallChange, IncAdj * 0.05); configUI.SetPropertyControlValue(PropertyNames.TexHeightScale, ControlInfoPropertyNames.UpDownIncrement, IncAdj * 0.01); configUI.SetPropertyControlValue(PropertyNames.TexHeightScale, ControlInfoPropertyNames.DecimalPlaces, 2);

Thanks for doing the more comprehensive scan, Red ochre! I should have done that. The fact that the values are all 0.25 from each other can hardly be coincidental. It is odd that the pattern only includes nine values.