https://bugs.kde.org/show_bug.cgi?id=499934
--- Comment #33 from Zamundaaa <xaver.h...@gmail.com> --- (In reply to tamodolo from comment #31) > Leting people change SDR only is a bug and not predicted by specs? No, it was how the initial naive implementation happened to work. As I wrote before, it was intentionally changed to make lots of better things possible, including but far from limited to actual Linux native applications being able to do HDR without making their app unusable. > At point I would call it a feature even if outside spec. Let people use > that. This is what people are asking. People here are asking for lots of different things, most of which are based on misconceptions about what things mean and how they work. Claims like HDR being only "proper" or "correct" if presented in the value of nits as the content specifies is just plain nonsense. To be clear, this is a complicated topic, the specs are terrible and confusing even for professionals, and it doesn't help that marketing companies did their very best to make HDR as much of a nonsense term as possible. So I don't blame anyone for not knowing everything about it, as long as they keep their claims about what's supposed to be "correct" and whatever minimal. But just like you're not thrilled by reading through tons of media standard documents or the literal years of development history of Wayland color management, I'm not thrilled spending a lot of time each day taking apart misconceptions about HDR, one by one, for each person commenting on this bug report. I would rather spend that time improving support for more efficient HDR video, the HDR calibration page, HDR screenshots and recording, and so much more... and bugzilla isn't even a good place for discussions in general. So if you want to continue such a discussion, please read https://zamundaaa.github.io/colormanagement/2025/03/31/about-brightness.html so that we hopefully have some shared base line of understanding, and then start a thread on https://discuss.kde.org instead (feel free to ping me there). Just like here, I can't promise that I'll answer quickly or anything, but it is at least a more suitable place for discussions, and a place where I'm much less likely to miss something, because it has an actual notification system and unread markers. And as mentioned before, if you specifically would like a feature to change the brightness of specific applications or content types (as far as that is possible to detect) rather than some arbitrary distinction between "SDR" and "HDR", that is entirely reasonable and you could make a new bug report about that. (In reply to TheFeelTrain from comment #32) > "To be frank" that's absolute nonsense. I asked a question in my last > comment to help clear up my "misconceptions" and you ignored it. You've > barely explained anything. I'm sorry, I get a lot of emails every day from this bug tracker alone, and sometimes one goes under. I assume you're referring to > Can you explain what this setting is *actually* doing then? You are > legitimately the only person on planet Earth who knows how Plasma's HDR > functions. All we have to go off of is what you've said here. Again, that's > one of my biggest issues with this change. It's confusing. ? The two brightness sliders decide the reference luminance. Specifically it's calculated as "5 + (Maximum SDR Brightness - 5) * brightness slider value". When the reference luminance is below 203cd/m², HDR content is darker compared to Plasma 6.2 or Windows. When it's above, it's brighter. In both cases, content may go as bright or dark as the display can do, there are (currently at least) no restrictions or attempts to fudge them in either direction. Videos are played as they're meant to be, so that dark scenes are dark, and bright ones are bright, relative to the brightness you're adapted to. Depending on the video, that might use the entire brightness range of the display, or it might not. That's not a problem; just like the Batman movies rarely use the full dynamic range of even an SDR screen, the movie gets shown as intended. If you'd like to lighten it up or make it darker anyways, make that feature request about changing brightness levels of an individual window... or check if your video player has built in options for that. Games are a bit more messy, because all the current HDR games are built for Windows. They require different calibration values than on Windows... but you can effectively always configure them to go as bright (or not) as you like. Linux native games, because of how we do HDR, will "just work" using the display settings, without you needing to do anything. > I only know from reading your reddit comments that you actually plan on > getting rid of this slider entirely and adding a separate HDR calibration > page. Why don't you communicate that information to the group of people who > subscribed to specifically get more information about that? You've > intentionally left everyone in the dark and then you're confused when they > have "misconceptions." It will hopefully be a lot less confusing, but the slider in the calibration page will do the exact same thing as the old one - configure what "100% brightness" means, no matter if SDR or HDR. If you're unhappy with the current state of things, you won't be any more happy with that calibration page. -- You are receiving this mail because: You are watching all bug changes.
