Rick Brewster

(The term you're looking for is "canvas")
 
This isn't currently possible but is something I'm considering for the upcoming 5.1 release. Maybe not the color but at least the brightness.

Paint.NET isn't a UI designer, so I think you've already got the right way of doing it from that video (lots of screenshot copy paste, etc.). I'm not aware of any plugin that would simplify this sort of task.

The latest NVIDIA driver has a fix for this
 

Paint.NET isn't tested on Windows Server. It isn't really officially supported, except as "you're on your own".

A bug in Firefox and/or Confluence

The ICO is already available -- just download the portable version, it's right there as paintdotnet.ico
 
You should be able to choose which file types are associated with Paint.NET by using the "Default apps" settings page (just search for "Default apps").

 
Unfortunately that's just what Windows does for Store apps. I think it's an ugly leftover from Windows 8/8.1. If anyone knows how to fix this, assuming it's even possible, I'm all ears for it. There might be some new thing that can be done in the Appx manifest.
 
I think the standard solution here is to create a batch file that uses the paintdotnet: protocol. Sometimes programs don't work very well when directly given the protocol, etc. "paintdotnet:%1", but they often easily handle batch files.

And/or adjust the Resolution (aka DPI) in Image->Resize.

Since you said you're not using this inside of Paint.NET then the answer is no. You cannot use Paint.NET's DLLs outside of Paint.NET. You can only use them from a plugin inside of Paint.NET. Both practically and legally speaking.

HistogramEffect is a weird one. First, be sure to look at the Direct2D documentation -- in CodeLab, put the cursor on "HistogramEffect" and press F1, which will take you to the wrapper's documentation, which has a "For more information, see Histogram effect" link. (this is a very important technique to know when working with Direct2D effects in Paint.NET!)
 
You can't just call DrawImage() inside of a command list's drawing scope like that and have it work. You have to actually draw it to a real target, you can't just use it in a command list and use its result like that because you aren't actually drawing when you create a command list. The drawing is deferred until after OnCreateOutput(), where Paint.NET takes the image you've given it (an "image" can be a command list btw) and draws it once for each output tile.
 
What you'll want to do is to create a temporary "compatible" device context to draw into "for real". ICompatibleDeviceContext maps to the Direct2D interface ID2D1BitmapRenderTarget. See here and here for some more info. 
 
HistogramEffect can only operate on images up to 4096x4096 pixels, so you'll have to break up the image into those chunks, run histogram on each one, and aggregate the results according to what you want to do with the data.
 
Here's an example CodeLab script I wrote that shows how to use it:
 
protected override IDeviceImage OnCreateOutput(IDeviceContext deviceContext) { StringBuilder text = new StringBuilder(); using (ICompatibleDeviceContext cdc = deviceContext.CreateCompatibleDeviceContext(desiredPixelSize: new SizeInt32(1, 1), desiredPixelFormat: DevicePixelFormats.Prgba128Float)) { // The HistogramEffect only works on images up to 4096x4096 in size. So we must loop through tiles of that size and draw each one separately. SizeInt32 docSize = this.Environment.Document.Size; const int tileEdgeLength = 4096; for (int tileTop = 0; tileTop < docSize.Height; tileTop += tileEdgeLength) { int tileBottom = Math.Min(tileTop + tileEdgeLength, docSize.Height); for (int tileLeft = 0; tileLeft < docSize.Width; tileLeft += tileEdgeLength) { int tileRight = Math.Min(tileLeft + tileEdgeLength, docSize.Width); RectInt32 tileRect = RectInt32.FromEdges(tileLeft, tileTop, tileRight, tileBottom); using CropEffect sourceImageTile = new CropEffect(cdc, this.Environment.SourceImage, tileRect); using HistogramEffect histogramEffect = new HistogramEffect(deviceContext); histogramEffect.Properties.Input.Set(sourceImageTile); cdc.BeginDraw(); cdc.Clear(); cdc.DrawImage(histogramEffect); cdc.EndDraw(); text.AppendLine($"for tile {tileRect}:"); IReadOnlyList<float> data = histogramEffect.Properties.HistogramOutput.GetValue(); for (int i = 0; i < data.Count; ++i) { if (i != 0) { text.Append(", "); } text.Append(data[i]); } text.AppendLine(); text.AppendLine(); } } } IDirectWriteFactory dwFactory = this.Environment.DirectWriteFactory; ICommandList commandList = deviceContext.CreateCommandList(); using (commandList.UseBeginDraw(deviceContext)) { deviceContext.Clear(((ColorRgba128Float)LinearColors.White) with { A = 0.25f }); using ITextFormat textFormat = dwFactory.CreateTextFormat("Segoe UI", null, FontWeight.Normal, FontStyle.Normal, FontStretch.Normal, 64); using ISolidColorBrush fillBrush = deviceContext.CreateSolidColorBrush(LinearColors.Black); deviceContext.DrawText(text.ToString(), textFormat, new RectFloat(Point2Float.Zero, this.Environment.Document.Size), fillBrush); } GaussianBlurEffect2 sourceBlurred = new GaussianBlurEffect2(deviceContext); sourceBlurred.Properties.Input.Set(this.Environment.SourceImage); sourceBlurred.Properties.StandardDeviation.SetValue(StandardDeviation.FromRadius(30)); sourceBlurred.Properties.BorderMode.SetValue(BorderMode.Hard); OpacityEffect dimSourceBlurred = new OpacityEffect(deviceContext, sourceBlurred, 0.5f); CompositeEffect output = new CompositeEffect(deviceContext, sourceBlurred, commandList); return output; }  
Here's what it looks like after running on a 5472 x 3648 image:

 

I have no idea why the test adapter is failing like that. Others have seen that same MVID error pop up sometimes when trying to use the WinForms Designer inside of Visual Studio, and it was completely vexing then too. There's something about the way these hosts are loading DLLs that just doesn't work. I'm pretty sure it's a Microsoft bug.
 
Also, I need to make sure you know that Paint.NET's DLLs are not licensed for redistribution or integration -- I'm not worried if you're doing automated tests on your own PC as part of developing a FileType plugin, but you can't (for example) put Paint.NET's DLLs into a public git repo, or use it in a CI system, or bundle it within your own apps or services, etc.

Yeah the Windows Print Wizard thing is very poorly behaved and super buggy. It hangs if you press ESC too quickly. It also hangs in certain error scenarios. Really really bad stuff. It's honestly just a big pile of garbage.
 
That's why I recently (v5.0.8) punted it to be out-of-process. I'd rather have a harmless zombie process than a hung Paint.NET window.
 
You can run "tskill paintdotnet" to wipe them all out. I'd like to have Paint.NET kill the print UI automatically when you exit the app, but I can't tell if it's a zombie process or if it's still in the middle of printing, which I'm loathe to meddle with.

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.
 

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

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.

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.

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

Performance looks fine.
 
You don't need to create that stroke style -- you can just pass null. That's the same as creating/using the default stroke style.

Well that's embarassing 😮 Thanks, I fixed it!

The fix is now available:
 

Also a little bit of poking around or searching and you would've found the answer already
 
 

It's nothing you did, it's just a bug that I'll be releasing an update for soon
 

I've been thinking of adding this soon, possibly (hopefully!) in 5.0.9.

Aha, now I see it

BTW this now exists: https://paintdotnet.github.io/apidocs/
 
It's obviously a work in progress, but it at least includes the API reference for namespaces, classes, structs, methods, and the like.