Rick Brewster

Is this for the interactive canvas, or only for Image->Resize? The canvas is using a combination of MagicScaler for mipmaps, and then Direct2D for presentation. Mipmaps via MagicScaler uses the Average (aka Box) interpolator kernel. For edge tiles that aren't the right size (e.g. not 2^n) it'll use a Linear interpolator kernel (same as Image->Resize's "Bilinear"). As for drawing it to the screen w/ Direct2D, I found that Linear sampling was too sharp, MultisampleLinear was too blurry, but a 50/50 blend between the two just felt perfect. When "very close" to a power of 2 (e.g. 50%, 25%, 12.5%, ...) it will only use Linear. (this is all just heavy enough that I need to drop the MultisampleLinear when hardware acceleration is disabled -- it'll just use Linear). So if you're talking about the canvas then it's a combination of all these things working together. Also, starting with v5.1, the whole rendering pipeline (after layer composition) is fully floating-point and uses linear gamma. (5.0 also uses linear gamma but has to bounce back and forth between floating-point/linear and integer/companded, for various reasons)

What they said. This isn't a case of the canvas now looking blurrier. It's a case of mismatched expectations. You (and so many others!) are accustomed to the wrong way of how things used to be presented, such that the correct way actually seems wrong to your eyes. It'll just take a little getting used to, but rest assured things are working correctly and optimally. When gamma correction is not used, it results in the image being darker and having increased contrast. This is incorrect, but can be subjectively pleasing to the eye. @saucecontrol deserves a lot of credit here -- he has been an unwaveringly patient mentor in this space, and I would not have been able to figure it out without his help and without his MagicScaler library

I take backwards compatibility very seriously with regard to plugins. Only occasionally will plugins break, and usually I find a way to make it work again in the next update. So, yes it's back-breaking work sometimes (v4.3 especially!!!!), but your expectations should be "it just works" and not "uh oh what's going to break." If something breaks, report it here! I'll do my best to fix it. (although do make sure to check if there's an update to the offending plugin(s) first)

It's not clear what you expect the selection to look like in this case. We only have these two muddy screenshots to inspect, and you mention "angles" but there is no rotation going on here. Are you saying the edges are what you want snapped to pixel boundaries? Or are you wanting the interior segments to also be pixel-snapped? If you want to work with pixelated everything, then in the toolbar you need to select Nearest Neighbor sampling along with Aliased selection quality. This doesn't look like a bug to me at all, just incorrect assumptions about how things are supposed to work.

There will never be "a linux version" of Paint.NET. It's all on the WINE folks.

It looks like the HEIF codec that Paint.NET is using, which is part of Windows, cannot handle this type of file. Using WICExplorer, it decodes some of the metadata, incorrectly says it's in 32-bit BGR format, and can't process the image frame at all. There (probably?) isn't anything wrong with the, WIC just can't do it. @null54's HeifFileTypePlus might have different results, but might not yet support 10-bpc either

This has been possible for ages, it's not news It's not supported (or even supportable) obviously, and doesn't even work quite right as you see. As far as I've seen there's been no movement on WINE's ability to support PDN 4.0+, which was released in mid-2014. For some reason they haven't managed to fully implement Direct2D or UIAnimation in the last ... decade. Direct2D is more understandable, but UIAnimation? *shakes head*

I said it could be as simple as a Windows Update being installed. "Another installation is in progress" couldn't refer to PDN in this case. But, in any event, Windows isn't lying. Another installation ... of something ... is in progress.

I've seen this for Stable Diffusion grid outputs, where you tell it to generate like 9 variations across 10 different models.

It is absolutely 100% without a doubt signed correctly. If it weren't, everyone else would be seeing this failure and my inbox would be overflowing. Also, I would've fixed it at some point in the last 2 months since this version was released. The problem is definitely on your end.

The image is too big .... different formats have different maximum sizes. There is no way around this. There is nothing you can do other than reduce the size of your image. PDN has no maximum size, although File->New won't let you go above 262,144px (you'd need like 512GB of RAM to work with an image like that and it would be suuuuuuuuuuuuuuuuuuuuuuuper duper slow ...)

It will be possible to work with the color profile in the upcoming 5.1 release. A significant portion of the "back end" rendering engine has been upgraded and rewritten to accommodate this and to get ready for future upgrades (e.g. high bit-depth support, and maybe even HDR support). ("c2" seems to be a size-optimized sRGB-ish profile that I've seen many images using ...)

@Timo Kinnunen There's a few things here. First, SampleMapRenderer is a bit picky due to some low-level internal Direct2D particulars. You will need to wrap Environment.SourceImage by using deviceContext.CreateBufferedImage(), and use that image instead of Environment.SourceImage. I've already seen this happen in another situation where it throws an InvalidGraphConfiguration, and I put in a special error message to direct folks to CreateBufferedImage(), but it looks like the effect graph you're creating is resulting in a cyclic graph instead. I'm not entirely sure how/why, but the DynamicImage framework (which SampleMapRenderer is based on) does some really really crazy stuff to achieve what it's doing, and it may be putting Direct2D into a state that just doesn't make sense. Second, SampleMapRenderer is definitely not the right tool to use for what you're doing. SampleMapRenderer is meant for distortion effects, like Effects -> Distort -> Dents, which sample pixels from all over the image. In order to achieve this, it requires a LOT of processing power in the general case (the internal effects have access to a property that helps to massively reduce that). You're only doing a sampling offset of +/- 0.25 pixels, so SMR is horrendously inefficient. Since your sampling is so simple, try using DisplacementMapEffect instead ( PDN docs, MSFT docs ). Outside of CodeLab, this would probably be best done with a custom shader written with ComputeSharp.D2D1.

This is almost certainly the issue. The code signing certificate being used via Azure Trusted Signing* requires a newer set of updates. If this were the case, then extracting the downloaded ZIP would have failed and it would be a different error. * formerly Azure Code Signing

When a new version of the plugin is released, however, you do need to update the plugin itself manually/separately. Paint.NET does not manage updates for plugins.

Glad to hear it!

Those could easily just be left over from old versions from when they were current

btw this future release is 5.1, and I'm hoping to push out a public alpha in the next few weeks, so be sure to try it out!

I would not go exploring the registry and deleting things. That is often a recipe for making things worse.

What version of Paint.NET are you on though?

Should just need a reboot, not a forced uninstall. "Another installation is already in progress" can just mean something as simple as Windows Update doing some stuff in the background.

The MSI is generally only used when doing a network-wide deployment, like in a school or business ("enterprise") or something like that. It's not really a good option for individual installs.

This is also an error that we've seen happen when someone uses one of those "slim down your Windows install! get rid of all the bLoAAAAtttt!" utilities. If you uninstall WIA, you can't use WIA to print.

You can just hold Ctrl when you want to sample the image instead of the layer (it says this in the status bar at the bottom, btw)

Yeah this doesn't really make sense... PDN never hides the image