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?

Hmm, naïve solution I'd come up with would be to 'record' a stroke to a separate surface the way it's done at the moment and then blend it with the correct alpha value with the rest of the image. Might actually work, though maybe memory and computation overhead makes this unfeasible.

The current behaviour is slightly airbrushy, though not really, actually. The sampled points are joined by a straight line which has the problem that the actual points are drawn twice. I don't think this is actually near from being intentional, but rather something that has to be cleaned up and was just something to make it work, as a better solution would be a bit more complex. You can, however use subsequent layers and draw in full opacity upon them and then adjust layer opacity, merging down to create only one. Cumbersome but works. One might argue that by changing the behaviour you lose temporal information of the strokes but I think they might be expressed better than by color

I do have a tablet and it helps a lot once getting accustomed to it but I almost never use lasso for selection. Porting my usual way of cropping non-boxy objects from a background to Paint.NET might be as follows: [*:72299]Make a new layer on top of it [*:72299]Draw an outline of the car with the brush [*:72299]Refine it with brush and eraser until it matches the car as exactly as possible [*:72299]Use magic wand to turn the interior of the outline into a selection (You may have noticed that this is actually a layer mask approach without layer masks ) Might be easier than to to this with lasso; though PdN's lasso actually gives more useful visual feedback than in most other programs

Rick, and most browsers interpret the image blocks as seperate frames for animation display Truecolor GIFs are actually possible (though not feasible): http://phil.ipal.org/tc.html

GIF is lossless as well but PNG offers better compression and an alpha channel.

reminds me of nconvert but this might actually not that much work, though this feature shouldn't reside in the Effects menu and I don't know whether effect plugins can appear anywhere else

Thanks for your quick reply, Rick. As for 1, the TIFF image was only an example as it was a direct conversion from camera raw fomat and I knew it to be 16 bit per channel, likewise I tried the quite large Photoshop file but I wouln't have been able to tell whether the problem lies on PdN's side or the plugin messes up (And I wasn't that eager to export that massive 470 MiB chunk of data onto my HD) 2) All I've read so far about the ink collector seems only to apply to Tablet PCs, right? So currently there is no way to use a pressure-sensitive tablet in general. Though the ink seems to be collected in vector strokes if I got that right. 6) Oops, I fell for not reading docs. But I can blame you for creating a program that is uable in such intuitively ;P 7) Ok, just was a question out of curiosity, I can understand your approach. 8 and to some extent 4) Actually, PS goes some other lengths in trying to perform well and I think the image swapping part there is self-implemented to make it consistent over the platforms they run on and to distribute it evenly over the set volumes. First compositing the layers on top of each other isn't actually done in full resulotion all the time but only for the current resolution and visible part of the image, nice to see if one has a quite large image with many layers. First thing PS does before saving is "Generating full-resolution composite" which can take a while sometimes Second it seems to utilize several 'snapshots' at various zoom levels. For Jpegs the 12.5Â % zoom is obviously pretty cheap to read from the file already And I wonder for the reason why 3.0 won't run on Windows 2000 anymore.

First of all, I use Photoshop regularly and am quite accustomed to that piece of software, so don't blame me if this may be too specific on things PS handles well and PdN doesn't. Secondly, I am very pleased with many aspects of PdN. I was quite surprised about the responsiveness of the program, even when calculating previews in background; has some glitches, especially with large images when cancelling a dialog but overall it performs better than anything I've seen with .NET so far. Some features are very cool, especially the line/curve tool with the clickable handles, translucent windows, some widgets, especially the one used in the Rotate/Zoom dialog and other details. It makes it clear that some people put a lot of effort and thought into this program and don't make the same mistakes that plague other software for decades now. For many of my suggestions there should be noted that I didn't dig that far into the source to tell whether it may be an enhancement that can be made without breaking the .pdn file format (due to the underlying object structure). I understand that backwards compatibility should be preserved wherever possible. [*:7be00] Support for color depths above 8 bit per channel. E. g. TIFF images with 16 bit color depth per channel are loaded but converted into 8 bit in the process. [*:7be00] Support for graphics tablets. I saw some things regarding the Microsoft.StylusInput namespace in the source though this may only apply to Tablet PCs or simply doesn't work on Windows 2000 (with which I am stuck currently). But I'd love to see some support to use a pressure-sensitive tablet to draw in PdN. [*:7be00] Layer Masks. I know there is a plugin that emulates this by importing an image and altering the current layer's alpha channel but this is a quite destructive method and should be approached in PdN itself, I think. [*:7be00] Effect, adjustment and fill layers that allow for later tampering with parameters. Especially if Effects would be allowed as layers PdN would have a significant advantage over PS and other leading image manipulation software. For all I know there's nothing out there that does this so far. [*:7be00] Better smoothing of quick strokes. Currently a straight line is drawn between adjacent mouse positions when drawing. Changing this to cardinal Splines might yield a smoother image, but it should be optional for obvious performance reasons. This approach might also allow for changing the stroke by dragging control points around like with the line/curve tool directly after drawing. [*:7be00] Maybe support for Bézier Splines beside the cardinal splines used for the line/curve tool. Bézier splines are easier to fit at the end of each other by simply lining up control points which is more difficult for cardinal splines since changing one control point alters the angle the line passes through its directly adjacent control points. [*:7be00] Is there a possibility to implement tools as plugins or only effects and file formats? [*:7be00] PdN doesn't scale well with huge images. I recently loaded a panorama of about 15 megapixels I stitched in Photoshop which made extensive use of layers and masks, so I had 5 or 6 layers in that file. PdN's memory usage rocketed up to 900 MiB at the end of the plugin loading the image, stayed there for a while and dropped to 470 MiB as soon as PdN was usable again. I don't know a trivial way to maybe optimize memory usage there as the whole image is actually an object that maybe won't easily be written to disk in parts and recalled into RAM as necessary.