tobibeer

I know... but that's the kind of click'n'wait I was hoping to avoid, especially with pixel intensive images. Since a certain update - though I couldn't tell since when, I believe it came with some dotNET Update or the last major update of pdn - performance of (many) basic actions seems to have dropped rather drastically. So, maybe I'm actually having a performace issue here, which of course would improve if I got to upgrade my single-core 2GHZ to something more recent / decent. Just to give you an idea, cropping a 3648x2736 image to let's say 3000x2000 easily takes 10 seconds and so does the undo.

That's a cool technique. Simple work-arounds aren't the worst idea after all. It seems, though, that resizing and moving a selection is more ressource-intensive than making one. Also, am I missing something or does it actually make more sense to delete that rectange (or other) WITHIN the area which you want to keep? Tobias.

Today I wished for a simple option that would allow to mask all non-selected pixels with any of the following: Black White FG-Color BG-Color Custom-Color Especially when croping rectangular sections this would give a cleaner impression on what the result actually looks like. This could be a single dropdown-button, integrated into the options-toolbar for selection-mode. Also, is there a chance that in the (near) furure, selections support alpha-masks, so that instead of a pixel being either selected or not, one had an option to use certain smoothing gradients together with the standard selection tools? Or have I been missing sth. and there's a plugin that already does apply these kind of "smooth edges" in order to cut or copy a selection. Sorry, if I wasn't quite using proper terminology.

Guess you're right... I mean, the "adapter" idea kinda sounds like a precursor to OLE, which doesn't seem to have been the most appreciated concept in software integration... whereas copy & paste usually works out of the box only requiring (hopefully) little tweaking of the imported data wherever pasted... and that extra bit of data / application management whenever you want to work in both worlds. Other than that, having vector and pixel tools smoothly integrated seems to be the designers dream, doesn't it? Just a never-ending story ;-)

I believe, the original post was not about implementing vector graphic elements into pdn but rather about a highly welcome interface (with inkscape) to smoothen such a workflow. Instead of even rendering svg in pdn, which would indeed be reinventing the wheel, one could rather trigger inkscape via commandline to export to png (or other) after having edited svg data... I guess there'd be a few things to consider, if one wanted to integrate both apps, e.g.: - svg data (how to embed ...or... link with respective external data) - image data to be loaded into a paint.net layer with meaningful size / resolution / placement This could even be like a "general adapter" to: - embed external data that pdn hands over when calling any app which offers an interface to pdn - embed returned data after having finished editing in that app - importing any image data exported by that app in an appropriate format into the current layer - applying meaningful size & placement parameters either before calling that app or after importing its output - indicating that external data are attached to a layer using an "embedded content" indicator (favorably the external apps icon), which may be removed at any time, only leaving the user with the imported image information I know, such things potentially bloat the whole idea of pdn, but then again it could also be just slick and utterly powerful... with a bit of a (longterm) team effort with the folks over at inkscape. Following the "adapter" idea, other data might be integrated as well using some rather simple "external tools" configuration (file).