paint.net 5.1 alpha build 8902.32650 (hotfix for PSFilterPdn)

[Tactilis]

2 hours ago, stupidgamer201 said:

i am happy to report that after updating my graphics drivers & turning off hardware acceleration, the problem is no longer happening

You really shouldn't have to turn off Use hardware acceleration for UI and the canvas if your graphics drivers are up to date and operating correctly. Disabling hardware acceleration will impact paint.net performance.

Do you still experience the flickering problem when Use hardware acceleration for UI and the canvas is on, now that you have updated your graphics drivers?

 

[Rick Brewster]

You definitely don't want to disable hardware acceleration. That is meant to be a short-term troubleshooting aid.

 

Make sure to re-enable the setting when the next alpha/beta build is released, as the flickering problem will hopefully be fixed.

[_koh_]

Additionally, your laptop can choose AMD / NVIDIA GPU for the UI rendering, so enable hardware acceleration and switch UI rendering to NVIDIA could be a better workaround.
You can change this through the Windows settings. PDN 5.1 removed open Windows settings button but I think it's better to have it.

[stupidgamer201]

2 hours ago, Tactilis said:

You really shouldn't have to turn off Use hardware acceleration for UI and the canvas if your graphics drivers are up to date and operating correctly. Disabling hardware acceleration will impact paint.net performance.

Do you still experience the flickering problem when Use hardware acceleration for UI and the canvas is on, now that you have updated your graphics drivers?

 

unfortunately, the problem persists when acceleration is on

[BoltBait]

That's why @Rick Brewster said:

 

1 hour ago, Rick Brewster said:

Make sure to re-enable the setting when the next alpha/beta build is released

 

[PCIe Team]

On 5/21/2024 at 5:16 PM, Vykranth said:

Hello,

 

a super minor regression I have found for all the 5.1 Alphas since the 5.0.13.

The menu bar has now a light blue extension all the width of the main window. In 5.0.13, the color is the same as the title bar.

When the paint.net window is maximized, the icon on the right side are between the solid color title bar and the light blue bar and that makes the icon rather odd.

 

Here are some screen shots

paint.net 5.0.13

paint.net 5.1 Alpha 8902.3265

 

These images are cropped from maximized windows because 2560 pixels wide are too large.

 

Good luck

oh dawg what the hell I just noticed that when I saw this post LMAO


oh and when not full screen, the color of the title bar was sadly not going down all the way like before the update.

Edited May 25 by PCIe Team

[Tactilis]

2 hours ago, PCIe Team said:

when not full screen, the color of the title bar was sadly not going down all the way like before the update.

By design. The title bar accent color should be reserved for the title bar.

 

It doesn't make sense for the title bar color to also be used for the paint.net Image List / Utility Windows icon area. In 5.1, that area is controlled by the paint.net Color Scheme Light/Dark setting.

[Rick Brewster]

1 hour ago, Tactilis said:

By design. The title bar accent color should be reserved for the title bar.

 

It doesn't make sense for the title bar color to also be used for the paint.net Image List / Utility Windows icon area. In 5.1, that area is controlled by the paint.net Color Scheme Light/Dark setting.

 

Not sure what you mean. This is clearly a bug, as discussed -- even by you! -- earlier in this thread

 

In any case, this bug has been fixed and will be in the next build

[Tactilis]

27 minutes ago, Rick Brewster said:

Not sure what you mean. This is clearly a bug, as discussed -- even by you! -- earlier in this thread

The bug in 5.1, I assumed, was simply the fact that the title bar was a bit too tall and was now encroaching into the tops of the Utility Windows icons.

I was assuming that in 5.1 you had decided to make the Image List / Utility Windows icon area follow the Light/Dark setting, so that the color of that area was distinct from the user selected title bar accent color. From your comment, it seems that my assumption was incorrect.

If the intention is to return to the 5.13 behaviour, then that's cool.

It doesn't actually affect me personally because I set Windows Transparency effects to Off,  Accent color to Automatic, Show accent colour on title bars and windows borders to Off, and paint.net Color scheme to Dark, which gives me a black title bar and Image List / Utility Windows icon area.

 

 

[Rick Brewster]

The title bar area and the areas to the right of the menu and toolbar ("image list / utility windows icon area") should be uniform (also included are a handful of pixels to the left of the File menu). That's the bug. I simply didn't test Win11 w/ accent colors enabled, I didn't remember it was even possible.

 

When the bug isn't fixed, the system buttons (min, max/restore, close) also look out of place. 

[_koh_]

Looks like SimpleColorProfile having problem. This grayscale script works in 5.0 but not in 5.1.

 

System.Runtime.InteropServices.COMException (0x800707DC): IsColorProfileValid (2012, ERROR_TAG_NOT_FOUND)

 

edit:

DC.CreateEffect(DeviceEffectIDs.ColorManagement)

works so likely somewhere in the wrapper.

 

protected override void OnInitializeRenderInfo(IGpuImageEffectRenderInfo renderInfo) {
    renderInfo.ColorContext = GpuEffectColorContext.WorkingSpace;
    base.OnInitializeRenderInfo(renderInfo);
}

protected override IDeviceImage OnCreateOutput(IDeviceContext DC) {
    var enc = DC.CreateColorContext(DeviceColorSpace.Srgb);
    var xyz = DC.CreateColorContext(new SimpleColorProfile(new(1,0), new(0,1), new(0,0), new(1,1), SimpleColorProfileGamma.G10));
    var source = Environment.SourceImage;
    var xyzimg = new ColorManagementEffect(DC, source, enc, xyz);
    var lumimg = new ColorMatrixEffect(DC, xyzimg, new(0,0,0,0, 1,1,1,0, 0,0,0,0, 0,0,0,1, 0,0,0,0));
    var rgbimg = new ColorManagementEffect(DC, lumimg, xyz, enc);
    return rgbimg;
}

 

[Rick Brewster]

On 5/27/2024 at 11:30 PM, _koh_ said:

Looks like SimpleColorProfile having problem.

I believe I have this working now (for the next build, of course).

 

This was happening because Direct2D just returns an empty byte array when calling ID2D1ColorContext::GetProfile[Size](). This then can't be wrapped in my internal ColorProfile class.

 

So instead I have it so that the Color Management effect wrapper will treat simple color contexts in a special way:

• If both the source and destination color context are simple, it will just defer to Direct2D's built-in Color Management effect (CME).
• If only the source is simple, then the built-in CME will be used to transform from source to scRGB, and then use the standard logic to go from scRGB to the destination.
• If only the destination is simple, then the standard logic will be used to go from source to scRGB, and then the built-in CME will be used to transform from scRGB to the destination.

"The standard logic" meaning all my workarounds for D2D's seemingly incorrect handling of various things that @saucecontrol helped me figure out.

 

Seems to work?

[_koh_]

My final code will be something like this and the "rotate" one being the 3rd case.
And if AbsoluteColorimetric is respected throughout the process, then yeah, I think it will be fine.
I'm just using ColorManagementEffect as ColorMatrixEffect without knowing the matrix in the ICC profile, so I need to bypass the rendering intent in this case.

 

BTW while I'm not gonna use those, DxgiColorSpace having the same problem.
 

protected override IDeviceImage OnCreateOutput(PaintDotNet.Direct2D1.IDeviceContext DC) {
    var abs = ColorManagementRenderingIntent.AbsoluteColorimetric;
    using var enc = Environment.Document.ColorContext.CreateRef();
    using var dec = DC.CreateLinearizedColorContextOrScRgb(enc);
    using var xyz = DC.CreateColorContext(new SimpleColorProfile(new(1,0), new(0,1), new(0,0), new(0.95045f, 1.08905f), SimpleColorProfileGamma.G10));
    using var source = Environment.SourceImage.CreateRef();
    using var decode = new ColorManagementEffect(DC, source, enc, abs, dec, abs);
    using var rotate = new ColorManagementEffect(DC, decode, dec, abs, xyz, abs);
    using var lumino = new PixelSwizzleEffect(DC, rotate, PixelSwizzle.GGGA);
    using var encode = new ColorManagementEffect(DC, lumino, dec, abs, enc, abs);
    return encode.CreateRef();
}

 

[Rick Brewster]

11 hours ago, _koh_ said:

And if AbsoluteColorimetric is respected throughout the process, then yeah, I think it will be fine.

 

The wrapper with the detours only supports Perceptual. I wasn't sure how to support the other modes, or how to support different choices for Source and Destination intent. I'm converting a single Source->Destination transform into something like, Source->SourceLinear->DestinationLinear->Destination or even Source->scRGB->DestinationLinear->Destination. So those middle transforms, which are often lowered to a 4x4 matrix transform effect instead of a ColorManagementEffect, I'm not sure what to do if the intents are different for source and destination. But if you're transforming between linear color contexts then it'll just be a 4x4 matrix transform anyway, at least when using the wrapper.

[_koh_]

I don't understand why ColorManagementEffect takes 2 intent parameters either. It goes against my understanding.
Feels like absolute intent is just clamp(invert(dstMatrix) * srcMatrix * RGB), but I might be wrong.

 

What I'm trying to do here is create a XYZ D65 image and use its Y as the luminance.
If I have RGB -> XYZ D50 matrix in the ICC profile or XYZ D50 PCS image, I only need ColorMatrixEffect to do that, but I have neither so I need to use SimpleColorProfile + ColorManagementEffect instead.

[Rick Brewster]

45 minutes ago, _koh_ said:

I don't understand why ColorManagementEffect takes 2 intent parameters either. It goes against my understanding.

@saucecontrol thinks it's for display profiles, as a LUT-based color profile can have different LUTs depending on the intent. So, it might not even be applicable.

 

I'm upgrading the CME wrapper so it supports specifying the same intent for both source and destination, even if it's not Perceptual.

 

If you need to use different intents, then you'll need the base D2D CME that you get with CreateEffect().

[Rick Brewster]

1 hour ago, _koh_ said:

What I'm trying to do here is create a XYZ D65 image and use its Y as the luminance.
If I have RGB -> XYZ D50 matrix in the ICC profile or XYZ D50 PCS image, I only need ColorMatrixEffect to do that, but I have neither so I need to use SimpleColorProfile + ColorManagementEffect instead.

 

As long as the source and destination intents are the same, this should work fine in the next alpha build. I added support for simple color profiles yesterday.

 

Simple->Simple will be performed directly using the base D2D effect.

Simple->Other will be performed by going Simple->scRGB with D2D's CME, and then scRGB->Other using the wrapper.

Other->Simple will be performed by going Other->scRGB using the wrapper, then scRGB->Simple using D2D's CME.

 

You can experiment with the current build, to see if this will work as you intend, by splitting your CME into two CMEs: use the base D2D effect for Simple->scRGB, then the CME wrapper for scRGB->Other. Or, CME wrapper for Other->scRGB, then D2D CME for scRGB->Simple.

[Rick Brewster]

16 hours ago, _koh_ said:

BTW while I'm not gonna use those, DxgiColorSpace having the same problem.

 

It might be that D2D's ColorContext and CME don't support most of these values. It's pretty happy with the ones that correspond to sRGB or scRGB.

[Rick Brewster]

These are the DxgiColorSpaces that you can create a Direct2D color context for:

RgbFullGamma22NoneP709 aka sRGB
RgbFullGamma10NoneP709 aka scRGB
RgbStudioGamma22NoneP709
RgbStudioGamma22NoneP2020
RgbFullGamma2084NoneP2020
RgbStudioGamma2084NoneP2020
RgbFullGamma22NoneP2020

I was not able to get any of them to work with D2D's CME. It just doesn't support them.

[_koh_]

1 hour ago, Rick Brewster said:

You can experiment with the current build, to see if this will work as you intend, by splitting your CME into two CMEs: use the base D2D effect for Simple->scRGB, then the CME wrapper for scRGB->Other. Or, CME wrapper for Other->scRGB, then D2D CME for scRGB->Simple.

 

Now I realized I can do some RGB -> scRGB (perceptual), then scRGB -> XYZ with ColorMatrix.

Not sure this is same as some RGB -> XYZ (absolute) though.

 

20 minutes ago, Rick Brewster said:

RgbFullGamma22NoneP709 aka sRGB
RgbFullGamma10NoneP709 aka scRGB

 

I remember at least those two worked at one point.

[saucecontrol]

13 minutes ago, _koh_ said:

Now I realized I can do some RGB -> scRGB (perceptual), then scRGB -> XYZ with ColorMatrix.

 

Yep, you can do that.  In fact, this gives you complete control of the XYZ representation and should be preferred.

 

13 minutes ago, _koh_ said:

Not sure this is same as some RGB -> XYZ (absolute) though.

 

The colorimetric intents (absolute and relative) don't really have any meaning for matrix-based color spaces because the matrices are pre-adapted to common whitepoint (D50) in order to make their XYZ representations compatible.  If you were to use color management to convert to XYZ, it would be D50 XYZ and would have to be adapted to D65 (or other) after the fact.

[_koh_]

34 minutes ago, saucecontrol said:

Yep, you can do that.  In fact, this gives you complete control of the XYZ representation and should be preferred.

 

Ah thanks for this. I just have a rough image like perceptual intent fits one cube to another.

 

40 minutes ago, saucecontrol said:

If you were to use color management to convert to XYZ, it would be D50 XYZ and would have to be adapted to D65 (or other) after the fact.

 

My initial thought was if I create a D65 XYZ profile and use it as the destination, ColorMatrixEffect will do RGB -> D50 XYZ -> D65 XYZ, but I need to use absolute intent to get the actual XYZ values.

[saucecontrol]

7 minutes ago, _koh_ said:

Ah thanks for this. I just have a rough image like perceptual intent fits one cube to another.

 

That's it conceptually, yeah, but the 'fit' is only done by matrix multiplication when dealing with a matrix-defined color space.  If the source cube is bigger than target, values outside that cube (gamut) go out of [0..1] range and can end up getting clipped (this may or may not happen within the color management step, depending on the values' numeric representation and whether a tone response/gamma mapping is required), preserving the perceptual appearance of the colors that remain in gamut.  If the source is smaller than target, the values are simply mapped to a smaller subcube within the target, which perceptually matches because you're just not using the full target gamut.

 

In other words, with matrix-based color spaces/profiles, rendering intent is meaningless -- 'perceptual' is the closest match that describes what you get, but there's no actual 'intent' involved in the processing.

 

Table-based profiles (like those used for CMYK) can actually define different tables for different intents, so the intent requested from the color management functions is used to select which table to use.  And in the event the profile doesn't have a table for your requested intent, you might either get an error or an automatic selection of a different table depending on the implementation.

 

16 minutes ago, _koh_ said:

My initial thought was if I create a D65 XYZ profile and use it as the destination, ColorMatrixEffect will do RGB -> D50 XYZ -> D65 XYZ, but I need to use absolute intent to get the actual XYZ values.

 

Yeah, I should have been clear that I was referring to the Profile Connection Space, which is always D50 in ICC-compatible color management.  You could define a device profile with adapted D65 XYZ output, but best case is you get the same basic output, just with reduced accuracy because of the extra rounding involved.  And this would still be a matrix profile, so intent would still be meaningless.

[saucecontrol]

By the way, you might have a look at https://www.color.org/profiles/srgb_appearance.xalter, which links an sRGB profile designed for use with rendering intents.  That profile is table-based rather than matrix-based like a typical RGB/display profile would be.

[_koh_]

16 hours ago, saucecontrol said:

In other words, with matrix-based color spaces/profiles, rendering intent is meaningless -- 'perceptual' is the closest match that describes what you get, but there's no actual 'intent' involved in the processing.

 

Oh, I didn't know that. I've been thinking when I do sRGB <-> Display P3 etc. changing rendering intent should change the outcome.

But yeah, this is the first time I actually tried to tweak the intent.

 

So I tested

 

Display P3 -> scRGB -> luminous = dot(RGB, new(0.212639, 0.715169, 0.072192))
Display P3 -> Linear -> luminous = dot(RGB, new(0.228975, 0.691739, 0.079287))

 

and those two give me the same result with handful of rounding errors.

Which makes color management compatible luminous effect simple as this. Thanks!

 

edit:

CME just outputs untouched non 0-1 range values when I do P3 -> scRGB, so going through scRGB is more useful than I thought.
I was assuming CME only outputs 0-1 range and I need to pick a normalize method like scale (perceptual), clamp (absolute)... but this wasn't the case.
 

protected override void OnInitializeRenderInfo(IGpuImageEffectRenderInfo renderInfo) {
    renderInfo.ColorContext = GpuEffectColorContext.ScRgb;
    base.OnInitializeRenderInfo(renderInfo);
}

protected override IDeviceImage OnCreateOutput(PaintDotNet.Direct2D1.IDeviceContext DC) {
    var gray = (float R, float G, float B) => new Matrix5x4Float(R,R,R,0, G,G,G,0, B,B,B,0, 0,0,0,1, 0,0,0,0);
    return new ColorMatrixEffect(DC, Environment.SourceImage, gray(0.2126f, 0.7152f, 0.0722f));
}