Created attachment 166726 [details]
HDR example with washed out colors

I have very similar issue but I'm using AMD Vega 64 with Acer PREDATOR X34 monitor.

When I set HDR mode in monitor settings and check "Enable HDR" in Display Configuration then all colors look washed out like missing saturation. This is most noticeable in System Setting icons on right side. When looking at photos/videos then it's not really that noticeable. YouTube videos look fine but it could be it's just not noticable due to not having a reference. Not sure if there is some test for this other than eyeballing :D I attached photos with HDR on and HDR off and while not that noticeable in photos you can kinda see it looks worse with HDR. For example put both images next to each other and look at wallpaper red cloud color at top.

I'm using Display Port and linux kernel 6.7.8 so it shouldn't be this issue https://gitlab.freedesktop.org/drm/amd/-/issues/3079 which is claimed to be fixed.

Also for me that SDR Color Intensity slider doesn't work at all, it does nothing - no visual change between 0% and 100%.

I also tried mpv --target-prim=bt.709 but didn't see any difference either.

Here's some info:

> $ kscreen-doctor -o
> Output: 1 DP-2
>         enabled
>         connected
>         priority 1
>         DisplayPort
>         Modes:  0:3440x1440@180*!  1:3440x1440@144  2:3440x1440@60  3:3840x2160@60  4:3840x2160@60  5:3840x2160@30  6:3840x2160@30  7:3840x2160@25  8:3840x2160@24  9:3840x2160@24  10:3440x1440@120  11:3440x1440@100  12:3440x1440@96  13:3440x1440@85  14:3440x1440@75  15:3440x1440@72  16:3440x1440@60  17:2560x1080@60  18:2560x1080@60  19:2560x1080@50  20:1920x1200@180  21:1920x1080@60  22:1920x1080@60  23:1920x1080@60  24:1920x1080@50  25:1920x1080@30  26:1920x1080@30  27:1920x1080@25  28:1920x1080@24  29:1920x1080@24  30:1600x1200@180  31:1680x1050@60  32:1280x1024@75  33:1280x1024@60  34:1440x900@60  35:1280x960@60  36:1280x800@60  37:1152x864@75  38:1280x720@60  39:1280x720@60  40:1280x720@60  41:1280x720@50  42:1024x768@75  43:1024x768@70  44:1024x768@60  45:832x624@75  46:800x600@75  47:800x600@72  48:800x600@60  49:800x600@56  50:720x576@50  51:720x576@50  52:720x480@60  53:720x480@60  54:720x480@60  55:720x480@60  56:640x480@75  57:640x480@73  58:640x480@67  59:640x480@60  60:640x480@60  61:640x480@60  62:720x400@70  63:1600x1200@60  64:1280x1024@60  65:1024x768@60  66:1920x1200@60  67:2560x1440@60  68:1920x1080@60  69:1600x900@60  70:1368x768@60  71:1280x720@60
>         Geometry: 0,0 2294x960
>         Scale: 1.5
>         Rotation: 1
>         Overscan: 0
>         Vrr: Never
>         RgbRange: unknown
>         HDR: enabled
>                 SDR brightness: 250 nits
>                 SDR gamut wideness: 100%
>                 Peak brightness: 542 nits
>                 Max average brightness: 400 nits
>                 Min brightness: 0 nits
>         Wide Color Gamut: enabled
>         ICC profile: none


> # cat /sys/kernel/debug/dri/1/crtc-0/amdgpu_current_colorspace
> BT2020_RGB

> # cat /sys/kernel/debug/dri/1/crtc-0/amdgpu_current_bpc
> Current: 8


> Block 0, Base EDID:
>   EDID Structure Version & Revision: 1.4
>   Vendor & Product Identification:
>     Manufacturer: ACR
>     Model: 2223
>     Serial Number: 277881511
>     Made in: week 9 of 2021
>   Basic Display Parameters & Features:
>     Digital display
>     Bits per primary color channel: 10
>     DisplayPort interface
>     Maximum image size: 80 cm x 35 cm
>     Gamma: 2.20
>     DPMS levels: Off
>     Supported color formats: RGB 4:4:4, YCrCb 4:4:4, YCrCb 4:2:2
>     First detailed timing includes the native pixel format and preferred refresh rate
>     Display is continuous frequency
>   Color Characteristics:
>     Red  : 0.6884, 0.3095
>     Green: 0.2578, 0.6699
>     Blue : 0.1474, 0.0615
>     White: 0.3134, 0.3291

> Block 1, CTA-861 Extension Block:
>   Revision: 3
>   Underscans IT Video Formats by default
>   Basic audio support
>   Supports YCbCr 4:4:4
>   Supports YCbCr 4:2:2
>   Native detailed modes: 1
>   Video Data Block:
> ...
> Colorimetry Data Block:
>     xvYCC601
>     xvYCC709
>     BT2020YCC
>     BT2020RGB
>   HDR Static Metadata Data Block:
>     Electro optical transfer functions:
>       Traditional gamma - SDR luminance range
>       SMPTE ST2084
>     Supported static metadata descriptors:
>       Static metadata type 1
>     Desired content max luminance: 110 (541.702 cd/m^2)
>     Desired content max frame-average luminance: 96 (400.000 cd/m^2)
>   Video Capability Data Block:
>     YCbCr quantization: Selectable (via AVI YQ)
>     RGB quantization: Selectable (via AVI Q)
>     PT scan behavior: Always Overscanned
>     IT scan behavior: Always Overscanned
>     CE scan behavior: Always Overscanned

> Failures:
>  Block 1, CTA-861 Extension Block:
>   Colorimetry Data Block: Reserved bits MD0-MD3 must be 0.
>   Video Capability Data Block: IT video formats are always overscanned, but bit 7 of Byte 3 of the CTA-861 Extension header is set to underscanned.
> EDID conformity: FAIL


SOFTWARE/OS VERSIONS
KDE Plasma Version: 6.0.1
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2

Created attachment 166728 [details]
Photo example with HDR disabled

Ohh it looks like SDR Brightness calculation is wrong. Atleast for me if I set it to max 542 nits then I get correct saturation but screen is WAY too bright (it daylight can be fine but at night I don't want to be blinded :D)
With HDR disabled I can set monitor's builtin brightness to 0% and colors are still saturated while screen being dim/non-bright.

So I think KWin does brightness wrong, it probably needs to increase saturation when decreasing brightness to keep same ratio so that colors don't look washed out or something like that.

No, it's not related to brightness, colors are just wrong, it's very noticeable when opening `htop` in Konsole and switching between HDR on and HDR off. The difference is so insane that HDR off looks WAY better and more "HDR" than with HDR on... Even with 542 nits those colors look washed out and not as "bright/colorful".

So this basically means in current state HDR on setting is unusable as daily default.

(In reply to mith3113 from comment #0)
> SUMMARY
> With HDR enabled in display settings, colors appear very washed out, as if
> my monitor is handling all colors like they're bt.709 instead of bt.2020.
> Increasing the SDR Color Intensity slider to 100% makes SDR colors look
> correct, and viewing HDR content with MPV I can set --target-prim=bt.709 as
> a workaround. The only similar issue report I've seen is this resolved one:
> https://bugs.kde.org/show_bug.cgi?id=479168 However I'm having this issue on
> an Nvidia gpu over both DP and HDMI.
While it may not be that specific bug, if NVidia implements the Colorspace property the same way Intel does, this could happen independently of the connector type. I'll confirm with someone from NVidia next week.

(In reply to Dāvis from comment #1)
> Also for me that SDR Color Intensity slider doesn't work at all, it does
> nothing - no visual change between 0% and 100%.
That's bug 482809

(In reply to Dāvis from comment #3)
> Ohh it looks like SDR Brightness calculation is wrong. Atleast for me if I
> set it to max 542 nits then I get correct saturation but screen is WAY too
> bright (it daylight can be fine but at night I don't want to be blinded :D)
> With HDR disabled I can set monitor's builtin brightness to 0% and colors
> are still saturated while screen being dim/non-bright.
> 
> So I think KWin does brightness wrong, it probably needs to increase
> saturation when decreasing brightness to keep same ratio so that colors
> don't look washed out or something like that.
You're not entirely wrong, the perceived intensity of a color is tied to its brightness, and that's much more noticeable when the color is less saturated. I'm not sure yet if we should do anything about that in KWin though.

(In reply to Dāvis from comment #4)
> No, it's not related to brightness, colors are just wrong, it's very
> noticeable when opening `htop` in Konsole and switching between HDR on and
> HDR off. The difference is so insane that HDR off looks WAY better and more
> "HDR" than with HDR on... Even with 542 nits those colors look washed out
> and not as "bright/colorful".
To some degree, that is expected. Without color management, wide color gamut displays show very oversaturated colors, and if you get used to that, the correct colors seem desaturated.
If that's actually what's happening for you though is hard do judge without objective measurements. If you have access to a colorimeter, could you measure what color gamut KWin actually outputs for sRGB apps? If you don't, a visual comparison with a display close to sRGB (most laptops have that) would also be useful.

Created attachment 166775 [details]
Window border effect: SDR version.

Same issue on 3 different screens, on AMD. Colors look washed out and wrong even playing with the sliders.

Created attachment 166776 [details]
Window border effect: HDR version.

(In reply to Zamundaaa from comment #5)
> While it may not be that specific bug, if NVidia implements the Colorspace
> property the same way Intel does, this could happen independently of the
> connector type. I'll confirm with someone from NVidia next week.

Thanks for this, I hope we get some useful information from them!

Created attachment 166908 [details]
Android (MIUI) HDR/Color settings

Created attachment 166909 [details]
Android (MIUI) HDR/Color settings

Created attachment 166910 [details]
Android (MIUI) HDR/Color settings

Created attachment 166911 [details]
Android (MIUI) HDR/Color settings

Created attachment 166912 [details]
Android (MIUI) HDR/Color settings

> (In reply to Dāvis from comment #1)
> > Also for me that SDR Color Intensity slider doesn't work at all, it does
> > nothing - no visual change between 0% and 100%.
> That's bug 482809
> 

Unfortunately it's not, I tested that MR https://invent.kde.org/plasma/kwin/-/merge_requests/5397 but it didn't change anything. Slider still does nothing.

> (In reply to Dāvis from comment #3)
> > Ohh it looks like SDR Brightness calculation is wrong. Atleast for me if I
> > set it to max 542 nits then I get correct saturation but screen is WAY too
> > bright (it daylight can be fine but at night I don't want to be blinded :D)
> > With HDR disabled I can set monitor's builtin brightness to 0% and colors
> > are still saturated while screen being dim/non-bright.
> > 
> > So I think KWin does brightness wrong, it probably needs to increase
> > saturation when decreasing brightness to keep same ratio so that colors
> > don't look washed out or something like that.
> You're not entirely wrong, the perceived intensity of a color is tied to its
> brightness, and that's much more noticeable when the color is less
> saturated. I'm not sure yet if we should do anything about that in KWin
> though.
> 
I don't see why there couldn't be more configuration options. For example I have Android phone with HDR and there are a lot of settings that I can adjust. See attached screenshots (Android (MIUI) HDR/Color settings) of setting pages. Such settings might especially matter for people with various forms of color blindness and such. Also even for me if I have been seeing colors wrong my whole life I don't really care that now they are more "correct" if they look worse to me. I think perceived good looking colors can be subjective. Of course if I'm editing some video/photo then I do want most accurate colors but my issue is specifically about how application icons/colors looks like with HDR mode on.


> (In reply to Dāvis from comment #4)
> > No, it's not related to brightness, colors are just wrong, it's very
> > noticeable when opening `htop` in Konsole and switching between HDR on and
> > HDR off. The difference is so insane that HDR off looks WAY better and more
> > "HDR" than with HDR on... Even with 542 nits those colors look washed out
> > and not as "bright/colorful".
> To some degree, that is expected. Without color management, wide color gamut
> displays show very oversaturated colors, and if you get used to that, the
> correct colors seem desaturated.
> If that's actually what's happening for you though is hard do judge without
> objective measurements. If you have access to a colorimeter, could you
> measure what color gamut KWin actually outputs for sRGB apps? If you don't,
> a visual comparison with a display close to sRGB (most laptops have that)
> would also be useful.

I don't have colorimeter and I don't really know what you mean but I took photos with my DSLR camera in 14-bit Adobe RGB where can compare HDR on vs off in exactly same settings: ISO 400, F/8, 1/50s

Here: https://drive.google.com/drive/folders/1oMdpwjY0JUAtXfkVxVoKM1E-yuqppmrd?usp=drive_link
They're unedited RAW so all information is there, you can open them with Gwenview and Darktable.

There can clearly see that left side red image is more orange in HDR on but more bright red in off. Also in Konsole yellow and cyan is more intense with HDR off.

That displayed red image is this so you can compare those photos with it => https://webkit.org/blog-files/color-gamut/Webkit-logo-P3.png (it's 16-bit color)

While looking into this I found bunch of interesting things, most programs can't render that image but shows only red without that logo being visible. I tested Firefox, Chrome on both Linux and Windows and Edge aswell and none could show it. Gwenview also doesn't show it. But KolourPaint and mpv can show it.

I also looked into HDR tests but I couldn't find any that would prove that HDR works... 

https://www.wide-gamut.com/test/image-hdr => says "It looks like your monitor or browser does not support HDR images :( The images below may not display correctly" - but maybe that test itself doesn't work rather than my HDR not working :D It doesn't work on my HDR phone either

and here https://webkit.org/blog-files/color-gamut/comparison.html I see image/color difference even in SDR...

I also tried looking at HDR movie with mpv but didn't see any difference either.

I installed `vk-hdr-layer-kwin6-git` from AUR and used
> ENABLE_HDR_WSI=1 mpv --vid=1 --aid=6 --vo=gpu-next --target-colorspace-hint --gpu-api=vulkan --gpu-context=waylandvk MOVIE

where MOVIE is
> hevc (Main 10) (HDMV / 0x564D4448), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 90k tbn

By the way another interesting thing regarding => https://webkit.org/blog-files/color-gamut/Webkit-logo-P3.png

My phone's photo viewer does show logo in these modes:
* Standard color mode is enabled (Contrast will remain constant)
* Advanced => Original identify color gamut automatically through color calibration

All other modes doesn't show it, not even P3 (Display all screen content in P3 color gamut)

I tried other phones aswell and none of them could show it.

Also Discord does show it on Linux and on my phone it does appear on Discord for few ms and then disappears.

I just tested Colorblindness Correction (in Window Management => Desktop Effects) and it doesn't work at all in HDR mode, I basically get nearly black screen (it's incredibly dim) so there definitively is some bug somewhere.

Can reproduce this bug on Nvidia Geforce 2080 Ti, Driver version 550.54.14 on an LG Monitor as well as an LG TV. 

The problem is not with either of the monitors as I tested that both work in HDR with a AMD Radeon 6700XT GPU on KDE Plasma 6.0

(In reply to Zamundaaa from comment #5)
> While it may not be that specific bug, if NVidia implements the Colorspace
> property the same way Intel does, this could happen independently of the
> connector type. I'll confirm with someone from NVidia next week.
I hope I'm not being too impatient, but has there been any update on this?

Not yet. NVidia is now aware of this bug and the possible cause, but the person that's usually responsible for this stuff is currently not available, so it might still take a bit for someone from NVidia to take a look.
I'll update this bug report when there's news

This problem came up for me after a recent kernel update on an AMD gpu with arch linux

The fix for this on the AMD side had to be temporarily reverted because of some regressions. You can follow progress on a more proper fix at https://gitlab.freedesktop.org/drm/amd/-/issues/3079