Color spaces are not considered

[xylobol]

Describe the bug Avalonia does not account for source/destination color spaces. For example, trying to render #ffff0000, which should be sRGB red, instead sends a fully red image to my display, which is calibrated to Display P3. Basically, it's assuming all inputs and outputs are sRGB.

To Reproduce Steps to reproduce the behavior:

1. Create an element set to a specific color (e.g. #ffff0000)
2. View on a calibrated wide-gamut display
3. Optionally, measure with a colorimeter

Expected behavior Avalonia should automatically keep track of the color space of the display the window is on, and adjust the color rendering accordingly.

Desktop:

• OS: Windows 11 21H2
• Version: 0.10.15
• GPU: Radeon RX 580 on the 22.5.2 drivers
• Displays (NEC MultiSync PA272W/PA271W/PA231W) calibrated using SpectraView
• ICC profiles loaded and available on-request

Additional context I spent some time looking into this yesterday, some of it's on the Gitter - basically, it looks like Direct2D and GDI+ don't account for it either. Skia natively supports using multiple color spaces. Chromium's handling of this could be a model for fixing this, if that's desired. I'm unable to test on any Apple platforms or Linux.

[pr8x]

Could you try passing SKColorSpace.CreateSrgb() to the constructor of SKImageInfo inside SurfaceRenderTarget.MakeImageInfo()? I think most Skia operations use the color space defined in the surface/image info.

[xylobol]

Where should I be looking for this?

[xylobol]

The new Advanced Color stuff might help with this on "modern" Windows devices. I'm still not sure how this would behave on Linux/macOS, though.