https://bugs.kde.org/show_bug.cgi?id=515402
Zamundaaa <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |INTENTIONAL --- Comment #6 from Zamundaaa <[email protected]> --- (In reply to Rynn from comment #5) > 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'. And it's handled just fine. > The sRGB = gamma 2.2 is a bit oversimplified: No, sRGB displays are very clearly defined as gamma 2.2 in its specification. While many people claim the opposite, they are spreading misinformation. Putting a very long story very short, the piece-wise transfer function is a historical artifact whose intended purpose isn't entirely clear even to experts, but while it's used in sRGB content creation, it's absolutely not how sRGB content should be displayed. > 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? Again, *you* are asking for fixing primaries while ignoring the TRC, displaying gamma 2.2 content as gamma 2.4. KWin does not, and will never ignore the TRC. > 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. Applications are assumed to be sRGB, and can opt into whatever colorspaces they support. Don't change the status of this bug report again. I'm happy to explain the basics of color management, but this is not the right place for that. -- You are receiving this mail because: You are watching all bug changes.
