Some features I miss a bit

[Joey]

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.

1. 
   [*: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.

[Rick Brewster]

Good writeup. Let me respond here:

1) Unfortunately this is not feasible. It would mean rewriting an enormous amount of code. Maybe in like ... version 10? Paint.NET isn't really optimized for handling TIFF's, either. Our TIFF support consists of about 3 lines of code that makes use of a bunch of built-in .NET stuff.

2) Tablet PC's are supported right now but only for the Paintbrush tool. Eventually the hope is to have a more generalized brush rendering system which can then apply the 'ink' to any tool that wants to use this (e.g. eraser)

3) Yup they're in the pipeline. Both layer-as-a-mask (affects all layers below it) and mask-for-a-layer(affects only the layer it is attached to). The barrier so far to adding this is not the rendering or the file format, or even performance. It's the UI: the Layers window needs to be badly rewritten, and the rest of the code needs to be aware of types of layers other than a bitmap layer. That type of code will also facilitate selecting multiple layers, drag and drop of layers, and who knows what else.

4) Going with #3, exciting things in this area are also planned (albeit in a relatively nebulous fashion so far). Unfortunately some effects are very compute-intensive (Gaussian Blur) but we'll see what we can do. I agree that these would be very very cool. Adjustment layers are a no brainer because their perf is great and they are simple (each output pixel only reads from one input pixel). One idea that Tom and I threw around for awhile was even having Rotate/Zoom applied in real-time to a layer. So you could hook the R/Z effect to a layer, and then start drawing and automatically have everything tilted and whatnot. But that requires a lot of 'plumbing' work first.

5) See #2, maybe, for the brush stuff. This also requiers a lot of tweaking to the input processing code.

6) You can use Bezier for the Line/Curve tool: just use the right mouse button when you drag the first control point. (FWIW, this is detailed in the help text in the status bar)

7) Tools as plugins are a bad idea, at least in the current form. The reason is that it would require us to open up the entire application object model to plugins. Which would really limit our ability to make changes here. For instance, between 2.72 and 3.0 there has been MASSIVE refactoring and rewriting of code, something that would not have been possible if we had Tool plugins (or, we would have broken all Tool plugins). Adding more extensibility points is currently not a high priority right now.

8 ) This is true. Paint.NET holds the entire image in memory. This was a conscious decision to balance development time and bug rates with the ability to scale with image size. But here's what I find interesting in your statement: you talk about swapping parts of the image in and out of memory. But hey, that's exactly what Windows' virtual memory does! So we load the whole image into memory and let Windows do the swapping. Unfortunately the locality works against us here:; images are two-dimensional but must be stored in memory as one-dimensional arrays. So the pixel at (0,0) is not necessarily anywhere near the pixel at (0,1) if the image is large enough. Photoshop, et. al. chop up the image in to rectangular regions and this helps a lot, which keeps (0,0) and (0,1) very close to each other. Anyway, this may sound lazy or something, but we are banking on the [unfortunately very slow in hindsight] migration to 64-bit and more memory to solve this in the long run. In the short term we can spend more time writing code and less time fixing bugs which would crop up with a much more sophisticated memory management and rendering system.

[A_Pickle]

PDN also doesn't scale too well with large masks... any chance of that being fixed?

3) Yup they're in the pipeline. Both layer-as-a-mask (affects all layers below it) and mask-for-a-layer(affects only the layer it is attached to). The barrier so far to adding this is not the rendering or the file format, or even performance. It's the UI: the Layers window needs to be badly rewritten, and the rest of the code needs to be aware of types of layers other than a bitmap layer. That type of code will also facilitate selecting multiple layers, drag and drop of layers, and who knows what else.

4) Going with #3, exciting things in this area are also planned (albeit in a relatively nebulous fashion so far). Unfortunately some effects are very compute-intensive (Gaussian Blur) but we'll see what we can do. I agree that these would be very very cool. Adjustment layers are a no brainer because their perf is great and they are simple (each output pixel only reads from one input pixel). One idea that Tom and I threw around for awhile was even having Rotate/Zoom applied in real-time to a layer. So you could hook the R/Z effect to a layer, and then start drawing and automatically have everything tilted and whatnot. But that requires a lot of 'plumbing' work first.

Oooh. For version 3.0, mayhaps?

[Rick Brewster]

No.

[Joey]

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.