Rick Brewster

You can also use the Pan (hand) tool. I tend to use Space + Left Mouse Button for panning, which is available when any tool is active and when View -> Zoom to Windows is not enabled (it's always enabled after opening an image). After opening an image, press Ctrl+B to toggle off View -> Zoom to Window, then Space + LMB for panning.

Sounds like Effects -> Blur -> Surface Blur ?

Looks like a mixup between linear and sRGB colors. Should be a straightforward fix.

This is a small update that fixes some bugs, adds a new Latvian translation, and updates the bundled AvifFileType plugin. Get the Update There are two releases of Paint.NET: Microsoft Store release (recommended) You can purchase it here. This helps fund development and is an alternative or supplement to sending in a donation. If you already have it installed, the update should happen automatically once Microsoft certifies the update, usually within the next day or so. To get the update immediately (once it's certified), you can follow the instructions listed here. Classic Desktop release Download the installer from the website. This is the recommended download if you don't have Paint.NET installed. It can also be used to update the app. If you already have it installed, you should be offered the update automatically within the next few days, but you can also get it immediately by going to ⚙ Settings -> Updates -> Check Now. Offline Installers and Portable ZIPs are available over on GitHub. Change Log Changes since 5.0.12: New: Latvian (lv) translation Fixed the Colors window sometimes showing up at weird sizes if the system scaling (DPI) was changed between sessions Fixed a crash in the Simulate Color Depth plugin (reported by @toe_head2001) Updated the list of libraries/contributors in the About dialog with some libraries that got missed (mostly from Microsoft) Fixed some clipped/invisible text in the installer when going through the Custom flow Added the GPU driver version to Diagnostics info Fixed HistogramEffect's Bins property https://forums.getpaint.net/topic/124026-getting-an-error-when-trying-to-use-histogrameffect-codelab-sample/?do=findComment&comment=618040 Updated the bundled AvifFileType plugin to version 1.1.30.0 (thanks @null54!)

Okay thanks; I've filed a bug for this, but I don't have an idea when I'll be able to look at it

Already answered by @Tactilis above. Upgrade your PC so it has more memory (RAM). This may require buying a new PC, since it looks like you're using a laptop and those can't always have their RAM upgraded. I should probably fix PDN itself so it reports this to the user (you) as Out Of Memory instead of File Is Corrupted.

Only History and Layers can be resized that way.

I got it down to 9.5s by calculating 3 px at a time 😎

Looks like a GPU driver or GPU configuration (control panel) problem, or you have some other software that’s interfering or causing the glitch. Like recording/broadcasting or overclocking software.

(Correction to data above: I've been using a 12K x 8K image for performance testing, not 18K x 12K)

I was able to convert this to a compute shader that calculates 2 pixels at a time: 10.5 seconds 😁 Increasing that to 4 pixels reduced performance, likely because of occupancy spillage.

If you're using the MSI then you need to supply properties (DESKTOPSHORTCUT=0 included) with whatever syntax it is that msiexe uses for specifying properties.

Did you read the instructions? https://getpaint.net/doc/latest/UnattendedInstallation.html And the MSI isn't extractable because it's provided separately now. https://github.com/paintdotnet/release/releases In general, unless you're doing a deployment across a large network of PCs and know exactly what you're doing, it's not a good idea to use the MSI.

The number of iterations is currently fixed, but that's an interesting idea

It may also be worth having PDN use smaller tiles in this case. I'm not sure whether it should be an option specified in OnInitializeRenderInfo(), or if PDN should somehow auto-detect that the effect is running "too slow" and automatically adjust downwards. I think both should be used in this case. Using either of the two (multiple rendering passes, or smaller tiles) will help a lot, but lower-end hardware will really need both. Here's how the tile size is calculated, based on the total image size:

I experimented with converting to/from linear space (e.g. WorkingSpaceLinear) -- and the results were substantially worse than with WorkingSpace. This is definitely an algorithm that should execute "within" the original color space.

I've been able to optimize this further vs. the original shader (at full sampling) in this post, cutting down the execution time by about 42% -- without using a compute shader (although that's my next step!) and while also improving quality. Here's how I did it: Instead of starting at a pivot point of c=0.5, I use the output of shaders that calculate the min and max for the neighborhood square kernel area. This then establishes the traditional lo, hi, and pivot values for the binary search. This is less precise than taking the min/max of the circle kernel area, but can execute substantially faster (linear instead of quadratic) because these are separable kernels. This has two side effects: 1) it increases precision in areas that have a smaller dynamic range, and 2) it supports any dynamic range of values, not just those that are [0,1]. Binary search provides 1-bit per iteration. I also implemented 4-ary, 8-ary, and 16-ary. I kept only 4-ary enabled because it has the best mix of performance and can reach 8-bits of output in 4 iterations (instead of 8 iterations w/ binary search). The 8-ary can hit 9-bits in 3 iterations, which is more than we need. The 16-ary can hit 8-bits in 2 iterations but because it's using so many registers it actually runs slower due to reduced shader occupancy. The search now produces the wrong result when percentile=0 because they can only output the value from the localized min shader, which is often providing the min value for a pixel outside of the circular kernel. This means you get "squares" instead of "circles" in the output. I special-case this to use a different shader that finds the minimum value within the circular kernel. It's possible to incorporate this logic into the regular n-ary shader methods, but it significantly reduces performance. For my performance testing, I used an 18K x 12K 12K x 8K image. I set radius to 100, percentile to 75, and then used either "Full" sampling (w/ your original shader), or the default iteration count (for my shaders). Your original shader took 30.7 second, while my 4-ary implementation takes 17.8 seconds (with higher quality!). The next steps for optimization would seem to be using a compute shader, which could calculate multiple output pixels at once. This should be able to bring that 17.8 down even further, meaning this might even be shippable as a built-in PDN effect! And a quality slider that chooses full vs. half vs. etc. sampling would also enable faster performance (like your shader does). I'd also like to separate each iteration of the algorithm into its own rendering pass. This would definitely require a compute shader, as it would need to write out 2 additional float4s in order to provide the hi/lo markers (so the output image would be 3x the width of the input image, and then a final shader would discard those 2 extra values). This would enable the effect to run without monopolizing the GPU as much and would help to avoid causing major UI lag. I don't think it would improve performance, but I need to see how it goes. Here's the code I've got so far. It's using some PDN internal stuff (like PixelShaderEffect<T>), but you can still translate it to not use the internal stuff.

Paint.NET isn't Photoshop ¯\_(ツ)_/¯ Unless I'm misunderstanding your initial problem description

The canvas size can only be an integer (non-fractional) number of pixels. So even if you type in an "exact" number of inches, it has to be rounded to the nearest pixel size. Because images are stored using pixels, not inches

That's there because you have a brush tool active. The circle shows the area that the brush will affect. You can switch to a different tool to remove it.

This should be fixed for good in the upcoming 5.0.13 update. Definitely let us know if it happens again after 5.0.13.

You can also use IGeometry::ComputeArea()

Status bar is your friend

This information isn't available in the plugin interfaces. I would simply add an option in the UI for low vs. full precision. From what I could understand from the algorithm, each call to HiLo() essentially calculates 1 bit of precision starting from the most-significant bit. When working with linearized pixels (that is, WorkingSpaceLinear instead of WorkingSpace), you need up to 12-bits because the values are spread out differently. The increase from 8 to 12 is pretty dramatic with some images, but I could only see very minute differences after that. Even 11 to 12 was very small, but still noticeable upon close inspection. Going forward it may be necessary to run up to 16 times, but it's easy to make it configurable for when that comes up.

btw this won't necessarily be true in future releases of Paint.NET First, the upcoming v5.1 will have color management -- so an effect will either receive pixels in the image's "working space" (which is currently de facto sRGB) which is still the unmodified BGRA32 values, or the pixels will be converted to the linearized version of the image's actual color profile (WorkingSpaceLinear is the default). As a backup, in case the color profile can't be linearized, the image will be converted to scRGB (linear sRGB). The effect's output will then be automatically converted back to the storage format of the image. Second, for future releases I am planning on adding higher-precision pixel formats like RGBA64 (4 x uint16), RGBA64Half (4 x float16), and even RGBA128Float (4 x float32). In other words, I would not rely on PrecisionEffect(UInt8Normalized) as a way to maintain the original precision -- because that won't be true in the future. I designed the new effect systems with future-proofing in mind!