paint.net 5.1 beta (build 9023)

[Rick Brewster]

46 minutes ago, Win080811 said:

Wait, is the ruler rendering problem fixed yet or waiting in the released build?

Fixed for a long, long time

[_koh_]

I remember I could still build .NET 7 plugins against .NET 8 PDN with some warnings, but I got some CS1705 this time, so I had to bump the build target to net9.0-windows.

I will do that anyway so it doesn't matter, but I'm curious this is a normal thing to happen.

[Rick Brewster]

You shouldn't be able to build a .NET 7 assembly which has dependencies that require .NET 8. If anything it was some weird glitch.

 

I always expect that when PDN bumps its .NET version that any newly compiled plugins will also have to bump their .NET version.

[_koh_]

Thanks. So just like minimum version for NuGet packages.

I just didn't know what the expected behavior is.

[IngridFJ]

@Tactilis Sorry to bother again, Tried to reïnstall, during automatic uninstall of 'old' version appeared an error message. There I clicked "OK". Then it looked like installing went further, but unfortunately it failed Impossible it says.

[Tactilis]

2 hours ago, IngridFJ said:

Tried to reïnstall, during automatic uninstall of 'old' version appeared an error message. There I clicked "OK". Then it looked like installing went further, but unfortunately it failed

Once again, it's because AVG has removed the file WinRT.Runtime.dll

You need to un-quarantine it, which will return it to the \Program Files\paint.net folder, and then you need to stop AVG interfering!

 

If you can't un-quarantine the file because, for example AVG has permanently deleted it, then there is another option to remove a 'broken' app installation - but please try un-quarantining first.
 

[Rick Brewster]

I would just get rid of AVG. It's hot smelly garbage.

 

Really the only help and advice we can give for AVG and Avast is "uninstall it" and "don't use it." Just use the built-in Windows Defender.

 

To put another way: it's reached the point where if you're still using AVG or Avast, and having literally any problems at all, then we can't help you. You first have to get rid of AVG or Avast.

[Ego Eram Reputo]

1603 error indicates you have a broken installation

 

Please use this utility to remove the broken installation:

https://support.microsoft.com/en-us/help/17588/fix-problems-that-block-programs-from-being-installed-or-removed

 

Afterwards, you should be able to install paint.net anew.

 

[Tactilis]

2 hours ago, Ego Eram Reputo said:

Afterwards, you should be able to install paint.net anew.

...provided you have got rid of AVG, or have stopped it interfering.

As advised by @Rick Brewster and by me you are better off uninstalling AVG and using Windows Defender, which is already present on your PC, be your protection.

[IngridFJ]

Problem solved! Restored files from Quarantine in AVG and made exceptions. Meanwhile installed PDN again. Yay! Have a great day y'all! Thanks for your kind replies and helping!

[Timo Kinnunen]

I noticed a curious bug, perhaps related to the UI code changes? If I change SDR content brightness from 0 to 50 in System > Display > HDR and then take a screenshot by pressing Win-PrintScreen, the brightness of some, but not all, UI elements increase in the saved screenshot, even though nothing of the sort is visible on screen. I've made a comparison image showing, from left to right, SDR content brightness at 0, at 50, and their difference boosted for easier viewing.

[_koh_]

I can reproduce this. While I've been using HDR mode for a while, never changed this setting.

Seems like everything but tool bar and status bar having wrong color, but only in capture, not visible on the screen.

This setting doesn't change SDR brightness on the screen. SDR white always mapped to the same brightness (80 nits maybe?). It only changes relative HDR brightness.

 

[Tactilis]

50 minutes ago, _koh_ said:

SDR white always mapped to the same brightness (80 nits maybe?)

There's an opinionated explanation of the SDR slider mapping here https://www.youtube.com/watch?v=9Z_XSKM96Zw with a suggested formula for finding the 'right' setting.

The video is just 2 min long if you ignore the 45s of sponsored promotion at the end.

 

[_koh_]

In that video, when the guy moves the slider, whole setting screen changes the brightness but mine doesn't do that.

I see brief flash, then everything but HDR contents goes back to the same brightness. Seems like another Windows mystery.

[Timo Kinnunen]

Brightness works differently depending on whether you're using an integrated screen like in a laptop or a separate monitor. And I forgot to mention that I'm using a separate monitor.

[Tactilis]

47 minutes ago, Timo Kinnunen said:

Brightness works differently depending on whether you're using an integrated screen like in a laptop or a separate monitor.

What do you mean by "works differently"?

[Rick Brewster]

8 hours ago, Timo Kinnunen said:

I noticed a curious bug, perhaps related to the UI code changes? If I change SDR content brightness from 0 to 50 in System > Display > HDR and then take a screenshot by pressing Win-PrintScreen, the brightness of some, but not all, UI elements increase in the saved screenshot, even though nothing of the sort is visible on screen. I've made a comparison image showing, from left to right, SDR content brightness at 0, at 50, and their difference boosted for easier viewing.

 

This isn't a bug in Paint.NET. The UI elements whose brightness is changing in the screenshots are the ones that are using Windows Advanced Color ("WAC"). They are the ones that are participating in color management and which can show colors outside the gamut of sRGB. Put another way, they are the UI elements that are actually taking advantage of your HDR display (or your WCG display, if you configure it that way in Windows Settings).

 

Windows manages the brightness of WAC and non-WAC elements in different ways, and screenshot tools (including the ones built-in to Windows!) have not caught up to this.

 

You'll either need to find a different screenshot utility that works correctly, or find an SDR content brightness level that produces correct screenshots, or switch your display to WCG mode (instructions are in Settings -> Color Management).

[Rick Brewster]

6 hours ago, _koh_ said:

In that video, when the guy moves the slider, whole setting screen changes the brightness but mine doesn't do that.

I see brief flash, then everything but HDR contents goes back to the same brightness. Seems like another Windows mystery.

 

Apps (or games) which use Windows Advanced Color, which are the ones that can take advantage of HDR or WCG, must manually adjust the brightness of their output based on the "SDR white level in nits" value that Windows provides. However, this value changes asynchronously and so apps will always be at least one frame behind when you are adjusting the SDR brightness slider. It is not a bug, it is just the way things behave, and is a consequence/corollary of the flexibility of HDR content in Windows.

[Timo Kinnunen]

I tested some more, using Snoop for MS Windows v0.34 as it exhibits the same issue as Win-PrintScreen and captures pixels values using APIs that have existed since Windows 2000:

BitBlt(hdcCaptureMem, 0, 0, width, height, hdcScreen, x, y, SRCCOPY);

I used 4 Snoop instances to capture 4 pixels in both SDR content brightness level 0 and 50, and then used Windows Game Bar to record the captured pixels and what the source approximately looked like on my screen.

 

The four samples were: SDR content from Windows Settings, HDR content from Windows Settings, cyan from color wheel in PDN Settings, and cyan from color wheel in PDN Colors window. The results show that the pixel values for SDR and HDR content that BitBlt captures from Windows Settings remain unchanged both at level 0 and at level 50. This is also the case for the color wheel in PDN Settings, but not for the one in Colors window. Even though both color wheels in PDN look like SDR content on the screen, the one in Colors window for some reason receives the SDR content brightness boost only when its pixels are read in SDR in BitBlt. This doesn't seem right, especially since the background color no longer matches the surrounding background color. It seems the same tonemap-to-SDR operation should occur without the value in the SDR content brightness setting affecting the result. Maybe this is a bug in the UI library?

 

This also raises a question: should the color gamut of the color wheel change depending on what the color profile is for the currently active image?

[Timo Kinnunen]

12 hours ago, Tactilis said:

What do you mean by "works differently"?

 

The HDR settings in Windows support article for Windows 11 contains these notes, which are... quite something:

 

Notes

• When you change the SDR content brightness setting for an external HDR display or HDR content brightness setting for a built-in HDR display, the effect it has on SDR content depends on whether it’s an external or built-in HDR-capable display:

  • On an external HDR display, this setting will change the brightness of SDR content relative to HDR content.

  • On a built-in HDR display, the brightness of SDR content is controlled by a separate brightness setting, or it might be controlled automatically. (For more info, see Change screen brightness in Windows.) Since the brightness of SDR content is already set, the HDR content brightness setting will change the brightness of HDR content relative to the brightness of SDR content.

• For built-in HDR displays, such as on HDR-capable laptops, both the brightness setting and HDR content brightness setting will affect the appearance of HDR content.

  • Brightness setting. When viewing HDR content in a bright area, you might need to increase the brightness setting to see the display. However, this will reduce both the effective dynamic range for HDR content in apps and the overall contrast because the darker pixels will appear brighter. To improve the appearance of HDR content, view HDR content in a darker area and use a fairly low brightness setting. If the brightness is set to a very low level, that will increase the overall contrast between the brightest and darkest parts of the content. However, there will be less details in the darker parts of the content. For example, if you have a scene in a movie that shows a dimly lit room at night, you might see less details in that scene.

  • SDR content brightness or HDR content brightness setting. For most times, using the default SDR or HDR content brightness setting or one close to it should work well. You could set the SDR or HDR content brightness setting higher to help improve the overall contrast between the brightest and darkest parts of the content. However, this would reduce the details in the darker parts of the content, such as a scene in a dark room at night.

[Rick Brewster]

1 hour ago, Timo Kinnunen said:

using APIs that have existed since Windows 2000

HDR content is only supported since Windows 10. BitBlt will have no idea what to do here, it is not a good reference point at all. If you want to capture content correctly you need to use the newer APIs like IDXGIOutputDuplication via IDXGIOutput5::DuplicateOutput1().

 

1 hour ago, Timo Kinnunen said:

This is also the case for the color wheel in PDN Settings, but not for the one in Colors window.

The color wheel in Settings is not using WAC / HDR.

 

1 hour ago, Timo Kinnunen said:

It seems the same tonemap-to-SDR operation should occur without the value in the SDR content brightness setting affecting the result. Maybe this is a bug in the UI library?

I'm not really sure what you're trying to figure out here. There's no bug in the UI library. I really think maybe you're just overthinking all of this? HDR is just complicated and confusing, and Microsoft didn't really land on a smooth experience for end-users or developers.

 

1 hour ago, Timo Kinnunen said:

This also raises a question: should the color gamut of the color wheel change depending on what the color profile is for the currently active image?

Yes. And it literally does, that's the whole reason for using WAC. Try use Image -> Color Profile and switch between sRGB and Display P3 and ProPhoto. There is a huge difference in the appearance of the Colors window, especially on a wide color gamut monitor.

[_koh_]

Web browsers are also affected by this, but interestingly only when showing non sRGB contents.

So at least it's system wide that's for sure.

 

[Rick Brewster]

9 hours ago, _koh_ said:

but interestingly only when showing non sRGB contents.

 

It's not about whether the content itself is sRGB or not. It's the presentation surface itself -- if it's Flip mode and FP16 or R10G10B10A2, which is what triggers Windows Advanced Color, then the brightness management is different than other (e.g. classic) presentation surfaces. You can have a WAC presentation surface that only has only sRGB content in it (that is, scRGB pixels confined to the [0,1] range), but whose brightness is then affected by the SDR content slider and which will then show up in screenshots like this. (Edit: I may be splitting hairs and being too pedantic here -- maybe I'm just rephrasing what you meant by "showing [non-]sRGB content", in other words  )

 

Like I said, this is an issue with the screenshot software, not with Paint.NET or with any other app. The software ecosystem just hasn't caught up yet. And it may take awhile, because both end-users and developers need HDR/WCG displays that are actually configured for HDR/WCG, and that isn't common yet even in 2024.

[Rick Brewster]

22 hours ago, Timo Kinnunen said:

Brightness works differently depending on whether you're using an integrated screen like in a laptop or a separate monitor. And I forgot to mention that I'm using a separate monitor.

 

I'm guessing this is because your laptop's screen has HDR enabled, while your external one does not.

 

Laptops have a higher chance of having HDR enabled, as the manufacturer can configure and manage the system+display holistically. External displays never have HDR or WCG enabled by default.

 

I definitely recommend enabling WCG mode if you can! Instructions are in Paint.NET's Settings -> Color Management. HDR is tough to recommend because it just requires too much "hand holding" unless you've got a properly configured/provisioned laptop (Lenovo's work great, not that others don't) or display (LG OLED TVs work great, at least).

[_koh_]

3 hours ago, Rick Brewster said:

It's not about whether the content itself is sRGB or not. It's the presentation surface itself -- if it's Flip mode and FP16 or R10G10B10A2, which is what triggers Windows Advanced Color, then the brightness management is different than other (e.g. classic) presentation surfaces.

 

I was a bit surprised that browsers switching some kind of modes depending on the contents, especially when everything is dynamically loaded. I didn't know you can switch them on the fly.

 

edit:

Is PDN doing the same worth it. Like using INT8 just for sRGB.