https://bugs.kde.org/show_bug.cgi?id=515402
Rynn <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|INTENTIONAL |FIXED --- Comment #2 from Rynn <[email protected]> --- (In reply to Zamundaaa from comment #1) > Unlike with Windows, everything is color managed in KWin. The profiling / > verification window of DisplayCAL doesn't support Wayland yet, so it's > assumed to be sRGB - and sRGB content is meant to be displayed as gamma 2.2, > so that's the expected result. Whether DisplayCAL 'supports' Wayland yet is irrelevant, it creates a standard ICC file. And the file was created in Windows. Saying 'sRGB is meant to be displayed as gamma 2.2 is an oversimplification that ignores why we use ICC profiles in the first place. You said it's assumed to be sRGB and displayed as gamma 2.2, but wayland-info for my session lists "bt1886" as supported transfer functions. interface: 'wp_color_manager_v1', version: 1, name: 46 supported rendering intents: perceptual relative absolute relative_bpc supported features: parametric extended_target_volume set_mastering_display_primaries set_primaries set_luminances windows_scrgb supported named transfer functions: gamma22 st2084_pq ext_linear bt1886 supported named primaries: srgb pal_m pal ntsc generic_film bt2020 cie1931_xyz dci_p3 display_p3 adobe_rgb If KWin supports bt1886, why is it defaulting to gamma22 for an ICC profile that is explicitly calibrated to a 2.4/BT.1886 curve? My monitor is physically 2.4; if KWin 'assumes' 2.2, it is creating a mismatch that results in washed-out colors. Also, a point of contention in online forums for sure, but for the record: 'sRGB' is not a flat Gamma 2.2 curve. It's a piecewise function with a 2.4 exponent (IEC 61966-2-1). If KWin is just forcing a generic 2.2 power law on everything, it isn't even following the "true sRGB standard". A color-managed compositor should be reading the TRC tags in the ICC to decide which of those 'supported' transfer functions to use, rather than just hard-coding everything to 2.2. The whole point of a color-managed compositor is to map the content to the actual display. If I have a display that is physically calibrated to 2.4 (BT.1886) and I give KWin a profile that says 'this display is 2.4', then KWin shouldn't just shrug and say "I'm assuming it's 2.2. If KWin ignores the calibration data in the profile and just does a 1:1 passthrough because it 'assumes' the monitor matches the content, then the ICC support in Plasma is currently broken for anyone who doesn't own a generic office monitor. Calibration isn't about 'sRGB content' but correcting the hardware output, which KWin does not currently do. I also have to ask: what happens if I calibrate my monitor to its native DCI-P3 or Wide Color Gamut (WCG) color spaces, which it supports? If KWin 'assumes sRGB' for everything, does that mean Wide Color Gamut support is also broken? Is KWin's color management currently limited strictly to sRGB office monitors? -- You are receiving this mail because: You are watching all bug changes.
