Rick Brewster

Fix what? If the image is smaller, then it's going to be smaller.

You're quite late to the game. It's been discussed way earlier than that. Exactly. You just made my point. Because I guarantee you that if I made this change, someone very soon would accidentally destroy the quality of whatever image they spent a lot of time on. I'm not interested in that happening. I don't know why you're even bringing this up. I've been extremely clear on this matter. I also don't know why you think you can elicit change by being such a smartass about it.

You really need to give us more information about what you're doing, how you're doing it, etc. You need to make it easy for us.

Well we don't know how to fix your custom hacked version of Windows

I'm not planning on "soft proofing" support, but it's not out of the question for later. Also, printing support in Paint.NET is ... not great. I'm not even sure if I can send along the color profile to the print wizard thingy.

This is going to be included in v5.1. I also have a Lenovo laptop (P16 Gen 1) with a calibrated HDR DCI-P3 screen etc. More details ... when I'm ready 😂 There's actually a ton of things that have to be reconsidered when color management is added.

This is what you might call the "old fashioned" way of reporting this information. Nowadays Windows just calls it "scaling factor". 96 "DPI" is 100% scaling, 192 "DPI" is 200% scaling, and so on. In other words, don't take that "DPI" value literally. It's not a real, physical DPI value. The DPI for the image you're working on is configurable via Image->Resize. Just set it to whatever you want it to be. You don't configure Paint.NET's DPI -- it doesn't have one, at least not as far as the ruler is concerned. You set the image's metadata with the DPI value you want to work with.

First, I recommend implementing a "Bitmap" Effect, not a "classic" Effect. You need the latest CodeLab for this. Then you'll have access to Environment.Document.Size, as well as all the other new stuff. The classic effect system is going to be deprecated soon (i.o.w. it'll be marked with [Obsolete] attributes, and you won't be able to compile for it), so there's no point in learning or using that system anymore. Bitmap Effect and GPU Image/Drawing Effect are the new replacements.

Are you using an ARM system? Please post the diagnostics info from Settings (gear icon at top right of main window) -> Diagnostics. Tyere's a "Copy to clipboard" button, click that and paste it here. Edit: For some reason I missed/forgot that the crash info has the diagnostics info already 🤦‍♂️ There might accidentally be some use of double-precision floats in the pixel shader code, which are not supported on some older AMD GPUs.

Paint.NET should be registering a profile with the NVIDIA driver to tell it not to use GSync. Configuring that yourself should no longer be necessary.

Yeah and it’s not something you’ll likely use that often. It’s not like the File menu has this behavior!

Just use Environment.Document.Size

Settings isn't a menu, it's just a button

This looks like one of those weird WinForms-ism bugs. The choices is to either have this goofy behavior, or remove the tooltip altogether.

Like I said earlier, it's obviously a bug in whatever other thing you're using. There is nothing to fix in Paint.NET.

"Analyze" ? "The analyzer" ? "The program" ? No idea what you're referring to. You have to be specific, we're not psychic.

The color profile is always loaded and preserved. You can convert the image to sRGB via the profile by using Image->Apply just like you already found. I'm planning color management support for a future release. No need to request anything, it's in the queue.

I've already got an issue filed for this, with fixing it scheduled for the v5.1 release. @sergiopedri reported this to me awhile back. The code has a comment in it that indicates there was a workaround for some other issue, so it's not safe to fix it in the next 5.0.x update -- it needs a full testing cycle, in other words.

Well you don't have to argue that, that's not really what's being debated What I'm saying is that this has been held up at the design stage, it needs to be whittled down to how exactly it should behave without anyone's pet features. It needs to be simplified, in other words.

I was able to reproduce this and I believe I fixed it

Works fine here, might be some configuration issue on your PC? I'm curious if anyone else is seeing this.

You're asking for a huge assortment of customization for this kind of feature, or for it to work in a way that's particular to your (desired) workflow. And that's basically why it doesn't exist -- everyone wants it to behave in a different way, and I'm not keen on adding a feature that won't even be useful for most of the people who want to use it, and/or that generates a constant stream of requests and bug reports.

This needs a recompile for PDN 5.0.11+. I changed the ContainerFormats properties from ref readonly to just regular value returns, and I missed that G'MIC was using them. I got this crash report from someone using v3.3.0 of the plugin: System.MissingMethodException: Method not found: 'PaintDotNet.Imaging.ContainerFormat ByRef PaintDotNet.Imaging.ContainerFormats.get_Png()'. at GmicEffectPlugin.OutputImageUtil.SaveAllToFolder(IImagingFactory imagingFactory, IReadOnlyList`1 outputImages, String outputFolder, String gmicCommandName) at GmicEffectPlugin.GmicConfigDialog.ProcessOutputImages() at GmicEffectPlugin.GmicConfigDialog.GmicThreadFinished(DialogResult result) at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor) at System.Reflection.MethodInvoker.Invoke(Object obj, IntPtr* args, BindingFlags invokeAttr)

AVIF FileType is missing? (or at least not tagged as bundled)

I don't think this is really necessary.