NinthDesertDude

Nah, because it's out of scope for a tiling algorithm to fix this: Notice the spacing after rotation between the images. I've shown how an algorithm might attempt to solve this, but the problem is that there are two angles: the image rotation angle, and the angle of the line. The smart algorithm on the bottom right would only work if image rotation matches angle of the line. "After rotation, 0 degrees" is what it would look like if the line was flat, showcasing why it's an undesirable algorithm. So just leave it to the user. Two options after drawing a line: - User wants X images on the line, spaced evenly - User wants to fit images on the line, which is this algorithm It doesn't matter if it overlaps; leave that up to the user to decide on aesthetics. Just give them options to make it possible. Default to a clean fit. Track previous image location and bounding box. In a for loop, apply scaling and rotation, storing new dimensions for each transformation. If the user ticks a checkbox to compute before rotation rather than after, use the scaled bounding box dimensions instead of scaled+rotated bounding box dimensions when computing offset to draw the new image. Include an arbitrary offset or percentage offset. Then update previous location and bounding box and go to next image. Modifications to that algorithm for location stutter, rotation/scaling jitter or progression are simple enough.

Ctrl + Alt + V to paste to a new image, then resize the canvas to the dimensions of the other canvas, setting the anchor to center, then copy to a layer over the original image. You should be able to get reasonably fast at it.

I see it for memory, sure. Don't know how to tell how many plugins are loaded or other programs are running.

You've got tons of plugins, lots of programs, or very little computer memory, methinks.

You can convert black-and-white photos to have transparent backgrounds with 100% accuracy using the Switch Gray to Alpha plugin.

Nope, because Paint.net doesn't support channel locking. But you can use the alpha mask plugin to essentially overwrite the alpha of another layer.

Oh hey, don't think I've seen this before. Default settings are basically Fragment with count 50, distance 5. However, you can avoid affecting alpha in this one, which I've found myself needing for the couple times I'm on a translucent shadow/highlight layer.

I think you've got an unhealthy outlook. It seems everyone here has been courteous and the so-called 'hijacking' was only an attempt to reproduce the same results. Three people had trouble reproducing the same results, but nobody said you wrote a bad tutorial.

Of course, @lifeday. Trix was great when I was a kid. I guess it's not just a breakfast cereal anymore. And @Seerose Great application with the lantern image.

It's difficult to guess you could click off-screen to switch to the previous color picker color, which is not intuitive for design. MJW's idea seems more in-line with maintaining usability. I think if clicking off-screen did that, somebody would log it as a bug

Ctrl + V to paste Ctrl + Shift + X to crop No extra image tab this way.

I'd imagine. It probably falls out of scope once you're working with an image larger than 65k pixels in any direction; I don't know what utility you might acquire from such a large image.

You can try some solutions listed on Google; maybe the stack overflow suggestions if you're on Windows 10 and you think your .net installation might be corrupt somehow. It's a thought, anyway.

I don't know about mirror printing preferences and whether they should be / are supported for printing. You can do layers -> Flip Horizontal before printing anyway.

I can't reproduce issue #4 on pdn 4.0.21. Issue #5 is actually a feature request. Textboxes consume keyboard input when they have focus, so you'd have to bubble up to application-level commands if Ctrl is held or something. But as with most requests, since there's only one programmer available to handle them, they have to be useful to a large number of people to go on the features backlist. Actually, I would agree that it would be useful because my workflow involves selecting a color, then clicking the toolbar so I can switch tools.

Your request has been raised once before, for plugins. Both plugins and built-in effects/adjustments should have the same behavior for start-up locations on screen, to avoid confusing users who would e.g. set the opening location in a setting (as I imagine not everyone wants it on the side). How it might work Built-in adjustments and effects could have their default location changed to the side of the screen. This would probably be a preference. Plugins that extend the paint.net dialog could have their default location changed a la changing the pdn dialog class. This is backwards-incompatible behavior. Or, plugins are handed the start location in the EnvironmentSettings, much like the user's brush size and color. The latter is the only sensible solution as I see it, since the others require either a preference that would only be respected by built-in plugins, or changes to existing plugin behavior. So this suggestion is made to Rick and it would be his choice whether or not to implement it. He has a backlog of things he's working on, too, so if he chooses to work on it at some point it probably won't be any time soon.

If the dithering algorithm locks bits and iterates through pixels with two for loops, replace the inner for loop with Parallel.For (look it up, it's easy to use) and you'll get some parallelization without much effort.

Good to know the report was useful

Interesting. Did you release v1.1 in response, or did you upload it within the last two hours? I suspect if your answer is no, then I was served an older version.

I managed to get an error that crashes PDN. Seems to occur for selections that include pixels along the bottom of the image; I didn't test other sides. It's an index out-of-range error. Details:

Any time. :)

Posterize and Pixelate are built-in effects. Posterize for the low-res colors; pixelate for the blockiness. There are free plugins for creating a limited color palette. Not sure what else you're describing.

His question's answered and everyone has their opinions, for whatever it's worth. It's apparent this request won't occur any time soon, so the utility of this thread has expired and we can go ahead and lock it, I say.

I'm suggesting that it's more likely that this behavior would be implemented internally in paint.net than exposed as an API, since a plugin could only use the API to make a key binding GUI anyway.