https://bugs.kde.org/show_bug.cgi?id=515402
Rynn <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|INTENTIONAL |FIXED --- Comment #5 from Rynn <[email protected]> --- I understand that technically ICC profiles describe a display’s response and that calibration for a specific gamma/TRC became a "workaround", but it has also become 'standard practice'. Even in a fully color-managed workflow, a profile should act as a correction layer for the actual hardware. A BT.1886 (Gamma 2.4) calibration still displays sRGB content correctly, but it ensures the display shows the intended tone response for a controlled environment. The color management system should translate between the source profile (sRGB) and the display profile (BT.1886 calibrated). By forcing everything to 2.2, the compositor overrides the calibration, effectively saying 'I know better than your profile', which defeats the purpose of providing a display ICC in the first place. > That's a pretty common myth, but it's completely wrong. The specification > very clearly states that sRGB displays are gamma 2.2. The sRGB = gamma 2.2 is a bit oversimplified: C′ = 12.92 × C for C ≤ 0.0031308 C′ = 1.055 × C^(1/2.4) − 0.055 for C > 0.0031308 Unless I misunderstand, that is not a pure 2.2 power law, it is *overall* 2.2 or extremely close, but this is not the core of the problem. This current logic feels backwards: When no profile is loaded: KWin stays out of the way, and I get my hardware's native "wrong" 2.15/2.2/2.4/whatever factory response (and full gamut for example, unless clamped in the hardware OSD). When a profile is loaded: I am giving more accurate data, but what I get is a less desirable visual result than intended. I don't own a reference-grade display; I use an ICC profile as a correction layer to reach a specific target. If I calibrated for 2.4, I expect to see that, not a "fixed" 2.2/sRGB version of it. I believe many users, photographers, video editors, and designers, want this level of control. If the intended use case for loading a profile is only for fixing primaries while ignoring the TRC/Gamma, then it is missing the 'Management' part of Color Management. Why does giving KWin more information result in a more restricted output? >Applications are assumed to be sRGB, not screens. Let me try again: I switch my monitor to DCI-P3. I load a DCI-P3-calibrated profile because I want to work in that color space. Then KWin assumes my applications are sRGB and clamps the gamut? I haven't tried it yet. Tl;dr the current implementation views ICC profiles as a map, whereas I, from a user's 'let me fix my hardware' perspective, view it as an instruction. -- You are receiving this mail because: You are watching all bug changes.
