Created attachment 185884 [details] Comparison SUMMARY If chromium uses WP_COLOR_MANAGER_V1_RENDER_INTENT_PERCEPTUAL it's wayy to dark and its brightness is inversly related to HDR brightness on wayland Specifically this is a side effect of: https://chromium.googlesource.com/chromium/src/+/78295f48c220860f587ce266227e0011d9a3ec41 which fixes https://issues.chromium.org/issues/449170664 The change was to replace WP_COLOR_MANAGER_V1_RENDER_INTENT_RELATIVE with WP_COLOR_MANAGER_V1_RENDER_INTENT_PERCEPTUAL STEPS TO REPRODUCE 1. Have a HDR display with 2. Open a chromium version containg the mentioned commit 3. Observe it's way too dark OBSERVED RESULT & EXPECTED RESULT See the attached comparison image. On the left, the affected version, on the right the unaffected version. SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 6.4.5 KDE Frameworks Version: 6.19.0 Qt Version: 6.10.0 Kernel Version: 6.16.12-1-MANJARO (64-bit) Graphics Platform: Wayland Processors: 16 × 12th Gen Intel® Core™ i7-12650H Memory: 32 GiB of RAM (31.0 GiB usable) Graphics Processor 1: Intel® Graphics Graphics Processor 2: NVIDIA GeForce RTX 3060 Laptop GPU Manufacturer: ASUSTeK COMPUTER INC. Product Name: Vivobook_ASUSLaptop N7601ZM_N7601ZM System Version: 1.0 ADDITIONAL INFORMATION
Another way to reproduce. At 100% brightness, open chromium with affected commit. Open a solid white rgb(255,255,255) background. With color picker, pick the color (I used KColorChooser). The result is #bababa or rgb(186,186,186)
Using the perceptual rendering intent is the correct thing to do, but if HDR metadata is wrong, tone mapping can have weird side effects. Chromium really needs to set HDR metadata to match the content, otherwise there will always be problems.
Just tested and this issue does not occur on 6.5.0, so I guess its related to improved tonemapping