LWChris

@Red ochre I looked at your plugin first, but the examples seemed way too complex for a simple non perspectivic non shaded 1px wide coiled line... maybe I need to look into it and play around with it.

Is there any method or plugin to create a line in the shape of a coil? Like this, but obviously "nice and clean"? I searched the plugin index for "spiral" (all seemed to be concentric), "coil" (1 result for Tesla coil lightning) and "twister" (no results) and I'm out of ideas what to look for. I can probably do it from hand, creating a single loop with mirrored parts from two differently sized ellipses for upper and lower half, and then copying that loop multiple times horizontally. But maybe there's something easier that I haven't found yet?

No it doesn't. PDN never crashes for me. It was running for about 3 and a half hours. Then I updated VS, and the instant the updater starts it crashed, then never again. It would be insanely weird coincidence if this happened in exactly that moment and had nothing to do with it. Yeah, my system has 16 GB and usually it's idling around 6-10 GB usage. What I find suspicious about this is the pagefile info from the crashlog. It says "20.420 MB pagefile (4.018 MB free)". But my pagefile is set to a managed size of 4096-8192 MB. So "20.420 MB pagefile" doesn't make sense unless it's combining the 16 GB = 16384 MB RAM + 4096 MB pagefile = 20480 MB - 68.5 reserved for hardware = ~ 20420 MB, but this calculation seems far fetched. So in order to verify whether those numbers make sense, how can I calculate them?

I just updated Visual Studio 2022 from 17.3.6 to 17.8.6. As soon as the VSInstaller started to download and update (i.e. not during the "Updating Installer" step but immediately thereafter), PDN, which had been sitting open in the background for at least several hours with just one screenshot clipping pasted onto the default canvas, crashed. I don't know if this is something that you can or want to look into, but I thought a) PDN would run independently and found it strange it would crash from updating an unrelated program, and b) every exception may still be worth catching and handling gracefully rather than crashing the app altogether Crash log attached. pdncrash.1.log

I would say the easiest way without plugins is: Color the background layer with your base color, eg. some █ dark olive green For each additional color of patches, repeat the following steps: Create a new layer (Ctrl+Shift+N) Reset colors to default black/white Use "Effects > Render > Clouds..." Use "Scale" to select number of patches: smaller values = more and smaller patches; bigger values = fewer but bigger patches Use "Roughness" to select uniformity of patches: smaller values = more uniformly sized, rounded patches; bigger values = more variously sized, jagged patches Use "Adjustments > Brightness/Contrast..." (Ctrl+Shift+T) to break it up into edges with sharp colors: Turn "Contrast" to 100% - this will basically split everything into either white or black Use "Brightness" to modify connectivity - adjust until you like either the size and distribution of white or black patches Use "Paint Bucket" tool (F) with "Flood Mode: Global" to color the patches in the desired color Use "Magic Wand" selection tool (S, S, S, S) with "Tolerance: 0%" to select the other parts and delete (Del) Tips: Rather than create one densely packed layer per patch color, create multiple loosely packed ones and mix the layer orders such that each color can overlay patches of other colors (e.g. Scale 100, Roughness 0.30, Brightness -40) If you have varying patch sizes, order layers from bigger to smaller patch sizes Create a top layer with medium sized patches of the base/background color

That's also how I do it in the PoC. What I find difficult about this is - how would you implement rotation? Because for a rotated ellipse for example, "top left" of input can't be "easily" reflected (or at least I wouldn't trust that mathematical calculations of reflected pixels about a randomly slanted symmetry axis will never ever create a result with a gap in the outline), and for output the "top left" isn't enough and also potentially not a rectangle. Sadly, I noticed it's not necessarily limited to 1px outlines if you consider rotation. This is how a 34x11 ellipsis with border thickness 2 looks like when rotated exactly 90°: While doing this example, I also noticed that in PDN, the outline of ellipses grow symmetrically around the set size. E. g. for a 20x20 rectangle with border thickness 6, all border pixels lie within that 20x20 (the fill is 8x8). But switch to ellipse, and now 3 pixels are inside, 3 are outside, meaning the resulting shape is actually 26x26 in size. However don't think changing that to a consistent behavior (where I prefer the rectangle one) would be detrimental to anyone (except for that one person drawing ellipses using an AutoHotkey macro on a daily basis). [Edit: I now realized that "rectangle" and "rounded rectangle" are the outliers here; all other shapes grow symmetrically around the set size, only those two grow within. I still like the rectangle's behavior better, because it preserves size while changing outline thickness or form fill mode from to ]

I have created a proof of concept for a custom renderer that handles circles, ellipses, and rounded rectangles. There is not yet any ability to rotate a shape and to be fair that is something I haven't even gotten around to think about. @Rick Brewster I published the code under MIT license. If you want to take a look, or use my code (or the "thickness = 1" bits) as base for your own custom renderer that you have not gotten around to since 2010, feel free. Also, if you want me to strip the code to only the "thickness = 1" case first, and/or want to see inclusion of rotations as well, please let me know.

Okay, so from what I have read here, the issue seems to be that PDN is using Direct2D for drawing shapes, and while the antialiased version are good, the aliased geometry is poor and that causes the problem. What's really interesting is that this only happens at thickness 1. Thickness 2 seems to be symmetrical for non-rotated shapes.

A 20x20 rounded rectangle with border width 1 and corner radius 4 looks like this: For some reason, 3 out of 4 corners get a "different" version of how a rounded corner looks like; only the top right seems to be actually 4x4. This is what radius 5 looks like: None of these corners have a 5x5 footprint. Here's radius 6: You get the idea... I tested all values from 1 to 10, and none of these values resulted in a symmetrical shape. I'm not sure it has always been like this, or if that's a regression, but something's odd about the rounding here, resulting in that I effectively cannot use this tool unless I want to check and tidy up 3 or all 4 corners, which may be feasible for radii up to 8, but beyond that it's very cumbersome.

Yes, my bad. I drew a shape without prior selection, and since it had that "9 nodes plus anchor" look it had the same UI features like a selection. So I just used that word without thinking about that an actual selection can also exist while creating a new shape.

Ctrl+Alt+V already exists, but I think it's not a problem. Ctrl+V can always just paste to the best of its possibilities. If you copied an editable state, it pastes the editable state, if you merely copied pixels, it pastes the pixels. My #1 use case is to alleviate the pain of my own stupidity: creating some object and customizing it, only to realizing I started on the wrong layer. Right now, there's not much I can do in that case, except for Ctrl+Z and start over again on the correct layer. A rich copy feature could be enabled for shapes but also lines, gradients, or even text I would think, and crucially it can copy and restore their editable states opposed to just the committed results, so making variants is much easier.

In a twisted way, this confirms my other point of "as a developer you don't care about sharing libraries to save memory and RAM". I am a professional developer of 16 years, and I've never [been] bothered to familiarize with the GAC or any of that stuff. You just reference a DLL in your project, it gets copied alongside your DLLs, you ship your own copies of the DLLs you need, and you never bother to try and make anything "shared" or access something that could probably be "shared" apart from the default runtime environment... Hence I didn't even know they abolished the GAC concept. But they probably did it for exactly that reason... managing 20+ of versions of a file which are all called "System.Windows.dll" in a "common" folder and have everyone who asks for "System.Windows" with an arbitrary version [range] get the right version and load all that conflict-free in an interoperable manner is a nightmare task. So we gave up on that front and that's probably a good thing for keeping everything smoothly running - everybody gets served exactly what they expected and nothing else.

Yes you are right, there is the "ant border" area selection and then the shape with its nodes and anchor etc. The cool part is - Ctrl+C might actually copy both, that is the selection and the shape configuration, such that Ctrl+V on another layer would create the same selection and the not-yet-commited shape. Or maybe just implement that as "Ctrl+Alt+C Copy objects", and keep Ctrl+C as it is.

I've used "Costura.Fody" in many different projects so far. It is as easy as adding the NuGet package to your project, and *poof* the next build should yield one big DLL instead of multiple small ones, no questions asked. At least that's been my experience so far. Installing the package will create a "FodyWeavers.xml" config file and add it to your project plus an xsd (XML schema definition for XML validation). Don't worry about those. It essentially contains nothing but an empty configuration node, which you could edit to manage linking to a finer detail, but the default config yielded from that empty config should be fine for most people and use cases. Also, I wanted to address the concerns about "loading a shared library twice": The proper way to distribute actual shared libraries would be to register them in the GAC (global assembly cache) which is a folder full of DLLs in all versions ever registered, that the assembly resolver looks into to find DLLs of a specific version [range]. Doing this however requires elevated process rights upon installation, and I think also special preparations for the DLLs (namely signing them with strong name keys, but then again IIRC only for .NET Framework not for .NET Core bla bla bla). Long story short, it's stuff that is a lot to ask for from your hobbyist programmer. So the main benefit of "sharing" has become not so much about RAM conservation but rather about code deduplication. A shared library from the perspective of a programmer is often just generic code that they use in multiple projects, so it's a library of shared code, that you only needed to write once, and maintain once, and bugfix once, etc. for all the projects to benefit from the work. Now that computer memory (permanent or RAM) has been increasing by orders of magnitude, loading the same DLL three or four times in isolated contexts is itching the perfectionist's brain because "this is not how it should be", but it's rarely ever a problem in the real world.

When I have an image and draw a shape, say, I pull a circle, and it's not yet commited, then there is this outline that suggests that the current "selection" is that shape. But when I hit Ctrl+C and then Ctrl+V, PDN pastes the whole layer again, not a new shape, because Ctrl+C without selection by default copies the whole layer. A clipboard can hold "rich objects" that can be converted to simpler things for uses outside the program, but stay rich for uses inside the program. For example if you create a table in MS Excel and make a graph out of that, then copy the graph, and paste it into Word, then Word will paste an interactive graph that's even still linked to the data in the Excel, meaning changing the data in Excel will change the graph in Word. But pasting that graph into PDN will create an image of that graph. It would be really cool if Paint.NET made use of that cool feature in .NET to copy and paste rich objects, such as shapes, multiple layers, etc. Then it could be implemented that when in "Shape creation mode", Ctrl+C copies the information that it is a shape, and Ctrl+V could commit the current shape and then create a new shape object on top that can be moved or edited, while Ctrl+X can put that shape into the clipboard and cancel creation, but Ctrl+V re-spawns that (useful if after creating the perfect shape you realize you're on the wrong layer, just cut, swap layer, paste, and continue creation from there). If the conversion interface is properly implemented for that "CopiedShape" object, this would also mean pasting that object to another Paint.NET file would also create an editable shape there, while pasting it into MSPaint or Word would just appear as if I had copied a rectangular image with nothing but the commited shape on a transparent background.

I have been thinking about creating a plugin called "Color Unmixer" to answer exactly these questions of reverse engineering. Sadly, I've not yet gotten around to think of a good custom UI. But luckily, having had those plans means I have a good understanding of how it should work, and I can do for you by hand what the plugin should've done if it existed already. So... here we go! The Maths, the Basics, and You Finding the semi-transparent overlay color boils down to a system of 4 linear equations that you can solve if you have two pixels with distinct known background colors "b1" and "b2" that were overlain by the same unknown semi-transparent foreground color "f". That is, as long as both colors were overlain by the same foreground color at the same opacity, you can mathematically calculate that foreground color and its opacity. Your image has several of these pairs, so it should be possible to work out the color. But first of all, one thing I noticed right away: the outlines are not affected by the glass, i.e. the oval outline of the eyes stays black, no matter if it should be "under" the blue tint or highlight or not under the glasses at all. So my guess is those outlines were on a separate layer ABOVE the glasses. But that's probably something you remembered anyway. For the other bits, there's 4 pairs for both the highlight and the tint on the glasses. I've marked them red, yellow, lime and blue here (the 3rd lime marker is in the top right). Any "pair" consists of one of the base colors (outside of the glasses) and then either the corresponding part on the tinted or highlighted part of the glasses, respectively. Having 4 pairs per unknown overlay color is cool, because we can use two to determine the color and its opacity, and the other two to check if our calculations "add up" (literally) as a sanity check. But first, here's the actual formula what the visible mixed color "m" becomes when a semi-transparent foreground color "f" is overlayed over the background color "b": mc = bc + (fc - bc) * falpha / 255 This formula is applied per channel "c". For example, for the red channel, the formula would be: mred = bred + (fred - bred) * falpha / 255 The keen-eyed can probably also see why we need 2 pixel pairs: since we want to know the semi-transparent foreground color, we have to re-arrange that formula to solve for the f's (more on that later). But we have to make a choice: we can either solve for the red channel value fred, or for the alpha channel value falpha. Any m/b pair will produce three equations, one for each channel, and we can use those to solve for fred, fgreen and fblue respectively. But we then need a fourth equation from a different pair to also give us some formula we can instead re-arrange to solve for falpha. With all that being said, there's two snags we need to pay attention to: Snag 1: If the values for a color channel between background color and resulting mixed color match, that means the foreground color used the same color value (or maybe a really close one with very low opacity) for that channel, but we cannot use that equation any longer to solve for falpha. This makes sense; if you overlay "some amount of redness" with "any transparency of same amount of redness", the resulting mix will still have that same redness value to it, no matter the actual transparency. [Side note: this is also visible from the formula. If mred = bred, that means the calculation must've been "mred = bred + [something that equals 0]". This can either mean that falpha was 0, which is not really interesting, because I think we agree the overlay was probably not 100% transparent, or "fred - bred = 0", which means "fred = bred", and that's what we stated when we said that background and foreground use the same red value, or "(fred - bred) * falpha / 255" is so small it gets rounded to 0.] Snag 2: This one is not as obvious from the formula, but becomes clear once you start crunching numbers. RGB colors are discrete values, that is: integers. The formula works perfect for floating values, where mixed red values like 15.7311248 would be a possibility. Alas, in the actual image the red value is probably either 15 or more likely 16. That's something we need to keep in mind, and it is the reason why many online maths solvers might probably say that the system of equations cannot be solved, because with all that rounding, the results between channels or different pairs etc. just not quite "line up" when calculating forwards and backwards again. But we'll deal with that later. The Highlights But now: to the actual solving! Let's start with the highlight color first, so the pairs are going to be the background colors from outside the glasses plus the respective color from inside the glasses where these have a highlight. For the blue pair, both m and b are #FFFFFF. As per snag 1, we cannot use that to determine the highlight falpha, but at least it's probably safe to assume it was "some transparency of clean #FFFFFF white". We'll use the yellow pair to find that alpha value: The background color for the yellow markers (iris) is b = #56C3F6, the mixed result on the glass is m = #89D5F9. Let's use the red channel, since it exhibits the most intense value change from bred = 56hex to mred = 89hex, which equals bred = 86 to mred = 137 in decimal numbers. Now let's re-arrange our formula to solve for falpha: mc = bc + (fc - bc) * falpha / 255 mc - bc = (fc - bc) * falpha / 255 (mc - bc) / (fc - bc) = falpha / 255 (mc - bc) / (fc - bc) * 255 = falpha There we have it, we can use this formula to get falpha: falpha = (mc - bc) / (fc - bc) * 255 Inserting the values for mred = 137, bred = 86 and fred = 255 (which, remember, we deduced from the "clean white"), we get 76.95266272189..., so basically 77. Hence we predict the highlight color to be "#FFFFFF with a transparency of 77". Let's test our theory by applying the original formula "mc = bc + (fc - bc) * falpha / 255" to the lime pair. Here are the known values for the lime pair (where "m" is the one located in the highlight, not the tint): b = #FBD574 = rgb(251, 213, 116) m = #FCE29E = rgb(252, 226, 158) f = rgba(255, 255, 255, 77) Now we plug the values for b and f into the formula, and see if that correctly predicts m: mred = 251 + (255 - 251) * 77 / 255 = 252.21 mgreen = 213 + (255 - 213) * 77 / 255 = 225.68 mblue = 116 + (255 - 116) * 77 / 255 = 157.97 And sure enough, if we round those values to whole numbers, we get m = rgb(252, 226, 158). Now for the red pair: b = #FCEDDA = rgb(252, 237, 218) m = #FDF2E5 = rgb(253, 242, 229) mred = 252 + (255 - 252) * 77 / 255 = 252.91 mgreen = 237 + (255 - 237) * 77 / 255 = 242.44 mblue = 218 + (255 - 218) * 77 / 255 = 229.17 Again, rounding those values to whole numbers, we correctly get m = rgb(253, 242, 229). Hooray, the highlight color is indeed "#FFFFFF with a transparency of 77", just like we predicted earlier. Yay for Maths! The Blue Tint Now let's do the same thing for the blue tint. This time, it's going to require a little bit more effort, since the tint color isn't obvious already. But worry not, it's the same maths like for falpha, but we're re-arranging the original equation to solve for fc instead of falpha, and then use that formula for red, green, and blue: mc = bc + (fc - bc) * falpha / 255 mc - bc = (fc - bc) * falpha / 255 (mc - bc) * 255 = (fc - bc) * falpha (mc - bc) * 255 / falpha = fc - bc (mc - bc) * 255 / falpha + bc = fc We can use this formula to get fc: fc = (mc - bc) * 255 / falpha + bc Let's use it on the yellow pair. Here are the known values: b = #56C3F6 = rgb(86, 195, 246) m = #3C93F9 = rgb(60, 147, 249) Plugging in those two colors for all three channels, we get three equations which are only dependent on falpha: fred = (60 - 86) * 255 / falpha + 86 fgreen = (147 - 195) * 255 / falpha + 195 fblue = (249 - 246) * 255 / falpha + 246 From the blue pair, we get these known values: b = #FFFFFF = rgb(255, 255, 255) m = #B2BDFF = rgb(178, 189, 255) This gives these equations: fred = (178 - 255) * 255 / falpha + 255 fgreen = (189 - 255) * 255 / falpha + 255 fblue = (255 - 255) * 255 / falpha + 255 Since we know (or rather: require) all equations come from the same f (i.e.: with the same fred, and the same falpha), we can essentially solve for falpha by equating yellow's fred and the blue's fred, and then re-arrange the resulting equation to solve for falpha: fred = (60 - 86) * 255 / falpha + 86 fred = (178 - 255) * 255 / falpha + 255 (60 - 86) * 255 / falpha + 86 = (178 - 255) * 255 / falpha + 255 -26 * 255 / falpha + 86 = -77 * 255 / falpha + 255 -26 * 255 / falpha = -77 * 255 / falpha + 169 51 * 255 / falpha = 169 51 * 255 = 169 * falpha 51 * 255 / 169 = falpha falpha = 76.95266272189349 Hey! That value looks awfully familiar, doesn't it? Yep, we landed on the same result as with the highlight color earlier. In hindsight, it's probably not too surprising that we got the same transparency value of "77" for both parts of the glass. The glasses were probably created on a separate layer using opaque colors and a uniform layer transparency of 77. But now we know for sure (and I could include the steps to calculate falpha for a non-trivial case). Anyway, back to the original "yellow equations". Now that we have confirmed that falpha is indeed 77, we can complete those equations and hopefully get our foreground color. So here goes nothing: fred = (60 - 86) * 255 / 77 + 86 = -0.10 fgreen = (147 - 195) * 255 / 77 + 195 = 36.04 fblue = (249 - 246) * 255 / 77 + 246 = 255.94 Here we have a classic example of snag 2. The "known" values were rounded, so reversing the operation has lead to slight deviations from the original colors. We get negative values such as -0.10, or values like 255.94, which would get rounded to 256 and thereby exceed the possible maximum of 255. But for now, let's reasonably assume f to be rgba(0, 36, 255, 77) and see where that assumption takes us. We can check it using the other two pairs - and that's why having such extra pairs for verification is so nice. Let's test red first. Known colors: b = #FCEDDA = rgb(252, 237, 218) m = #B0B0E5 = rgb(176, 176, 229) Assuming f = rgba(0, 36, 255, 77), the formula suggests: mred = 252 + (0 - 252) * 77 / 255 = 175.91 mgreen = 237 + (36 - 237) * 77 / 255 = 176.31 mblue = 218 + (255 - 218) * 77 / 255 = 229.17 Great news! These values check out for our observed m. Now, for our final test, we check the lime pair. Known colors: b = #FBD574 = rgb(251, 213, 116) m = #B0A09E = rgb(176, 160, 158) And one last time, assuming f = rgba(0, 36, 255, 77), the formula suggests: mred = 251 + (0 - 251) * 77 / 255 = 175.21 mgreen = 213 + (36 - 213) * 77 / 255 = 159.55 mblue = 116 + (255 - 116) * 77 / 255 = 157.97 Spot on! Nice. The Answer And there we have it. From using nothing but the final result and Maths, we can deduce: The glasses were made using a highlight color of #FFFFFF and a tint color of #0024FF, on a layer with "77" transparency. Cheers, Chris

The options for the (sp)line tool are great, but unfortunately, it's currently super annoying to draw a simple line with 1 bend, because all line options have 2 intermediate points. I can think of two different ways to achieve this: Add an option to select the number of intermediate points on a line, maybe from 0 to 8 or something. I guess this should be pretty straight-forward to implement since the spline code is already doing point-to-point and shouldn't really care if it's 2nd to 3rd point or 6th to 7th. The dropdown for the number of in-between-points could become disabled once the first grab-point was moved. Allow the "Shift" modifier to have an effect while pulling intermediate points, such that the dragged point snaps to imaginary rays radiating from the neighboring points. Here's an example of number 2: pulling the handle in the red circle and holding shift will make the handle snap to the closest dashed line in red. Alternative: holding Shift snaps to the rays of one point, holding Ctrl snaps to the rays of the other point. Holding both snaps to both.

Love the "Draw from center" feature, it was just today that I would've needed it to draw circles around a point. If only I had figured it out two hours earlier 😅

None that I know of, but you can place your cursor over the dropdown textbox (without clicking it) and then use the mouse wheel to change the size. That is less cumbersome than typing numbers, and allows you visualize between the given options. If you're interested in visualizing ALL different options (e. g. the ones between 48 and 72) then you're out of luck AFAIK, but maybe I'm not aware of something.

Yes, I asked Rick about it and he linked the same post. I did that for version 1.1.1 together with the color fix - still seems to work? 😅

@CStrike @AndrewDavid @Hecatia @Jacer @Ego Eram Reputo I just released a total remake (project file wise) of the plugin, but it should look and behave the same. You can download it from my webspace (that's still the same link as always and in the first post, just copied it here for your convenience). I had to do some "weird" referencing to be compatible with .NET 6 and Windows Forms and Paint.NET, because PDN seems to reference a DLL named WindowsBase, Version=6.0.2.0, whereas enabling WinForms in a .NET 6 project seems to add references to WindowsBase, Version=4.0.0.0. Please let me know if this version works for you. On a side note: I am (and have been) aware that the plugin UI doesn't look great with dark mode. Essentially that is because the font color changes, but the background color doesn't (because I set that to white explicitly, to avoid lots of differently colored boxes, IIRC). I will look into this and see if I can fix that as well, while I'm working on the plugin anyway. Edit: well, that was easier than I thought - I immediately replaced the download with version 1.1.1, which also looks nice with the dark theme.

I will try to update this plugin soon, since I still want to use it myself. Hang in there! EDIT: (Editing, since I don't want to bump the thread when there's no actual news) I managed to get my hands on the new VS2022 so I can lift the project to .NET 6.0. I hope it will all be done by the end of March.

Btw, I loved your idea so much, I created an image using the portal I made. I used my "Modify Channels" plugin to "isolate" the portal so I could put in another image inside it. First, you may want to use "Effects > Distort > Dents..." on the "disk" layer to give the outer edge a little "flaming" look. Maybe duplicate that layer and give it a beefy Gaussian Blur with a huge radius for a "halo" effect. Then on the other layer again, apply slight Zoom Blur. Finally, apply "Dents..." with low "Tension" on the two black spike layers for a more "smokey" appearance. Finally, merge all layers onto a black background: Then find my plugin under "Adjustments > Modify Channels...". Using two steps "Alpha = Identity Average" and then "Grayscale = Constant 255", you will isolate the portal. Together with two beautiful stock images from pexels (Road, Countryside), I created this:

I can think of some other idea: Get the "Light Rays" plugin by MadJik (download link and installation guide in first post; don't forget to restart Paint.NET) Create a new, square image, and clear the white background Select white as primary color Create a white disk (aka filled circle w/o outline) in the middle Create a second layer above the one with the disk Select black as primary and secondary color, but set the secondary color to fully transparent Open the plugin dialog from "Effects > Texture > Light Rays...", and adjust the settings: Disable the "Use anti-aliasing" (it renders faster now and we'll blur the layer in the end anyway) Enable "Use random" Set "Reseed" from 1 to 0 (this will be important later) Set "Random factor" to 80 (the rays will now have their ends slanted) Set "Ratio of the rays" from 0 to 100 (don't worry if it looks chunky for now) Reduce the "Radius External" slider from "100" to a number so that even the rays reaching out the furthest still don't touch the disk's edge, effectively leaving the "white ring". Adjust the slider so that you're satisfied with the thickness of that ring. Memorize that number, but reduce it by about a quarter for now (so 40 becomes 30 for example). Set "Quantity of rays" from 50 to several hundred, depending on your image size. The larger the image, the greater the number of rays to make them "fine". Confirm Repeat the effect a few times, until there are just a few white dotted lines remaining in the center. Don't repeat it too often though, or the outer edge will lose its spiky appearance. Rather undo then re-apply (Ctrl+Z, Ctrl+F) the effect several times for other Using a wide black brush, paint out the most obvious white lines from the inner area that shall become pure blackness. Open "Effects > Blurs > Zoom Blur..." and set the Zoom Amount to 100 (this is why we reduced the external radius by 25% in step 7.6) Add a third layer Open "Effects > Texture > Light Rays..." again This time, select the actual external radius you memorized earlier (e. g. the 40) Repeat the effect several times again Use "Effects > Blurs > Zoom Blur..." once more, but this time with the default "Zoom Amount" of 10 You may want to try out other effects from the "Blurs" menu as well. Fragments with a high "Fragment Count" (see 2nd image) and/or "Unfocus" on "Radius" 1 work very well, too. Try around and take what pleases your aesthetics. My results (black background added for better visibility):

Yes, I sometimes do that as well when it is a lot of layers, because this approach requires less switching of layers. I still have to "dump" my currently mixed color on a temporary layer though. I suggested adding a new keyboard shortcut, because introducing a shortcut "Shift+Del" that currently is not doing anything different from pressing "Del" alone is the least invasive change, especially since all it does is NOT doing a second step, so it is in a way "less destructive". So even persons who would for some reason use "Shift+Del" right now all the time would not be disturbed because it doesn't make something they used to do impossible. Another idea would be to make "Del" consist out of two steps in the history, "Delete" first, "Deselect" second so I could Ctrl+Z to get the selection back. This is the same behavior that is already used when you press Ctrl+D while drawing a line or shape within a selection. It commits the drawing, then deselects. In this case "Del, Ctrl+Z" would be my chord to "Delete and retain selection". I'm absolutely fine with that, too.