This is a continuation of https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14#note_2152254 because this is off-topic in that thread.
> No, we did widening. The Deck's internal display has a modest gamut > that is < 71% sRGB. If games do wide (well, full sRGB or wider) gamut, then why would you need to make that gamut even wider to fit nicely into a significantly smaller gamut display? Here's what I think happened. You have a game that produces saturation up to P3, let's say. When you did the colorimetrically correct matrix conversion (CTM) from BT.2020 to the "modest gamut", you found out that it is horribly clipping colors, right? If you then removed that CTM, it means that you are re-interpreting BT.2020 RGB encoding *as if* it was "modest gamut" RGB encoding. This happens if you simply apply the input image EOTF and then apply the display inverse-EOTF and do nothing to the color gamut in between. Adjusting dynamic range does not count here. This is an extreme case of saturation reduction. (Note: Doing nothing to numbers equals to applying a major semantic operation. Like telling someone something in cm and they take that number in mm instead. Or metric vs. imperial units. Color space primaries and white point define the units for RGB values, and if you have other RGB values, they are not comparable without the proper CTM conversion.) That does not look good either, so after that re-interpretation you added saturation boosting that nicely makes use of the capabilities of the integrated display's "modest gamut" so that the image looks more "vibrant" and less de-saturated. However, the total effect is still saturation reduction, because the re-interpretation of the game content RGB values is such a massive saturation reduction that your boosting does not overcome it. I could make up an analogue: Someone says they are making all sticks 50% longer than what you ask. You ask them to make a stick 100 long. They give you a stick that you measure to be 15 long, and they still claim it is 50% longer than what you asked. How is this possible? The length spaces are different: you were thinking and measuring in cm, they did mm. They did give you a stick of 150 mm, which is 50% longer than 100 mm. But from your perspective, the stick is 85% smaller than you asked. If one had started by converting to a mutual length space first (referring to the correct CTM), there would be an initial agreement of how long is 1. Thanks, pq
pgp8icu9jG5jk.pgp
Description: OpenPGP digital signature
