Joey

Ok, some more stuff on the line-undo thing. I initially thought it might have been a problem with my mouse (kinda like double-click when only single-clicking) but using my trackpoint here at the notebook works, too. It does, however, only seem to work zoomed-in, not when at 100 % zoom level. This might indicate a relation to the jumping coordinates. It doesn't work always, though. However, the start pixel (or pixels with AA turned on) are already present when drawing the line, as in mouse button not yet released. And this pixel isn't removed by using undo. This can be observed by reducing alpha to 50 % -- the start of the line should be darker, then. Reproducible here about half of my tries (zoom level 2400 %). It seems to be easier to reproduce when zooming in as far as possible.

This may actually be all the same bug, though I'm not sure of that. All following bugs are tested with antialiasing turned off, might work with AA enabled as well, though. When drawing a line, and then undoing it, the start pixel of the line remains, although it should have been undone with the line. Video: http://hypftier.de/temp/line-undo.avi When drawing a rectangle, some corners may disappear. Video: http://hypftier.de/temp/rect.avi When moving the mouse over a zoomed-in image, the exact pixel position of the cursor (in the picture, not on the screen) seems to jump in a 2×2 pixel square, seemingly random. This may be the cause for the aforementioned rectangle bug. Video: http://hypftier.de/temp/pixel.avi Another bug I observed when drawing lines: Sometimes, when drawing an exact diagonal line from bottom right to top left and moving the cursor (while drawing the line) one pixel to the left, the second pixel from the top left disappears. Hard to recreate, a sloppy video of it: http://hypftier.de/temp/line-pixel.avi

This is due to the crawling ants around the selection. You can slow down PDN to a crawl when doing Add Noise and then click somewhere in the image with the magic wand (many selection outlines). Minimizing PDN should solve it if you don't want to lose the selection (programs can't draw to a minimized window). PDN isn't shy of using your CPU when no-one else will but this particular issue is a bit nagging, especially since the ant-drawing is done in the UI thread and thus menus, dialogs, &c. are unresponsive as well.

I see the same issue here (Graphire 3, Vista Business x64) sometimes, though not only in PDN but also in other applications that use ink (i.e. InkBall). It does appear at times even when the tablet isn't plugged in but I couldn't find a definitive cause of the problem yet. I suspect, though, it's not PDN's fault here.

Paint.NET does not support (and to my knowledge won't ever) images with a channel bit depth greater than 8. I think 16 bpc TIFFs were opened but converted to 8 bpc in the process but it's been a while since I tried. You may be able to convert the image with nconvert to something you can open in PDN, however (as a temporary workaround).

Do you possibly have any selections active? Whatever will be drawn outside an active selection won't appear (as the selection confines changes to itself).

When dragging a file on PDN it asks whether to open the file or insert it as new layer into the current image. However, when having no image opened the option to insert the image as new layer is useless in that context. To reproduce: 1. Start Paint.NET 2. Close the Untitled picture by using Ctrl-W or the close button on the tab bar. 3. No image should be open now. Drag an image file onto Paint.NET. 4. A dialog should appear, asking you whether to open the image or to insert it. Expected behaviour: The image should be opened, since the dialog makes no sense in that context. Observed behaviour: PDN fails gracefully by creating a new Untitled image and inserting the file as new layer if the option is selected. Opening images from that dialog works as expected and wanted.

I'm having this problem occasionally (Windows 6 SP 1 here, Wacom Graphire 3; didn't happen since I installed the latest drivers, though). This seems to affect every program that uses the Ink API here. So, Windows Journal, InkBall and PDN are all affected. This may be a problem with my tablet driver, though.

Ok, short explanation how this stuff works: the plugin attempts to perform ClearType on arbitrary images effectively. This basically means that the physical ordering of the red, blue and green subpixels on an LCD screen is utilized by antialiasing with colored pixels. Since the subpixels are usually ordered horizontally in R-G-B order (on most screens; some use B-G-R and then this plugin will yield pretty blurry images) you can take advantage of that and effectively triple the horizontal resolution (not exactly, there are some things that prevent you from doing so). What this algorithm does, according to its website is combining the red and blue pixels into one. This is, however, not how subpixel antialiasing works usually. You can see that the results are inferior to ClearType or similar methods by the color fringes it produces, especially in the first and third example pictures. (Also what the author states, that the perceived brightness of red and blue together is about the same as green alone is a bit away from the truth. Perception levels are (in RGB order): 30, 59, 11) What ClearType does, is not simply distributing the pixels directly on the available colored subpixels but rather distributing the available energy on adjacent pixels as well. This does indeed make the image more blurry but has the distinct advantage that we perceive it as crisp as before and we don't have the color fringes the other method produces. Also, usually you start out with an image of tripled width, since there are three subpixels

The open (cf. filled) arrowheads may point in the wrong direction. Steps to reproduce: 1. choose line/curve tool, select »Arrow« from the end cap list (»Filled Arrow« works as intended) 2. draw a line 3. make a curve from the line. Drag the nubs with the left (i. e. primary) mouse button, since it works correctly with Bézier curves (as tangent calculation is easier) 4. play around a bit and watch the arrowhead point a way different from the line. This end cap is probably self-drawn (as it bears little resemblance to the filled arrow, which may be from .NET's line drawing facilities) and it will point the same way a line would point when drawn through the last control point and the end point (which is fine for Béziers as that _is_ the tangent in the end point but not for cardinal splines).

After a quick doodle with PS and this adjustment I think you may be able to replicate the effect using the Conditional Hue & Saturation Effect.

You may want to look in the next university library, but be warned: most image processing algorithms have roots in signal theory and are heavily math-based, so some basic understanding of that might be helpful. For specific problems I found Wikipedia to be a pretty good source of a rough overview; again, heavily math-based with most algorithms. Another option would simply be to ask here in the forums, if you have a specific problem. More than one person here has written an effect plugin and might be able to help.

I'd recommend trying out with the clone stamp, paintbrush and color picker tool. Create a new layer above your image where you paint (makes things cumbersome with the color picker, though) and pick a nearby color to paint over the spor or use the clone stamp. You may consider soften the edges by using a blur on the layer (that's why we did this in a separate layer) which makes the correction less noticeable if you didn't find the right colors. In the image above it's pretty easy this way because the spots are all on a pretty uniform background. If they cover important parts of your image you may have to invest some more work. A pressure sensitive tablet helps here, as well, especially when working with brushes Hopefully some day we might get Poisson image editing (see Photoshop's healing brush) in PDN, which makes things like these much easier

The net result is only that you get a blurrier picture. I just tried with PDN with your stair technique and then again with one pass, the result is only that the stair image is blurrier. Since those are algorithms designed to interpolate date that isn't there, you won't get a better picture just by re-interpolating from data that already was interpolated. The error just multiplies. For comparison: Original Enlarged with 'stair interpolation' Enlarged in one pass Difference between the two above

Since I do a little rendering I loved that effect since it enabled me to easily get depth of field without leaving that to the renderer (which greatly prolongs render times). Anyhow, I wanted to try implementing that effect for Paint.NET and after finally understanding how convolution works and in which way one can avoid using integrals I came up with some code that works pretty similar to the Unfocus Effect. Results are not exactly equal and my code is way slower, so I thought I could maybe utilize Unfocus. Now the Lens Blur filter utilizes a depth map which you could either hand-paint for photos or easily generate with 3D applications for rendered scenes and simulates depth of field while you can select where the focus lies. After looking how Unfocus worked (and trying to grasp what was done there with pointers) I think I would be unable to feed that code with varying levels of blurriness. Or may that still be possible somehow?