https://bugs.kde.org/show_bug.cgi?id=499934
tamod...@gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tamod...@gmail.com
Resolution|INTENTIONAL |---
Status|RESOLVED |REOPENED
--- Comment #29 from tamod...@gmail.com ---
I was strugling with the new HDR sliders a lot and after not finding a good
setting that was as good as 6.2 I ended up here.
I'll just sumarize things to not take much time of anyone (reason available for
those who want it). Consider this a colection of good practices (much based on
users feedback from reddit and this issue)
1. sRGB color intensity never worked on nVidia hw. Feature is broken for nVidia
users.
2. Max SDR brightness should not control HDR brightness. This causes double
tone maping and that's undesirable. Just leave that to the screen settings (as
mentioned before, these screens already do the work to make HDR looking good
inside their limitation).
3. If 2 must be included anyway then include an option to ignore it and leave
HDR as is (also known as HGiG mode).
4. If 2 exists to controls the furute KDE UI then this must be a separated
option just to control the UI and nothing else.
5. Brightness is a useless slider as is now. If the intent is to directly
control the native screen backligh then it must be set to do nothing when it
cannot change that. Again just leave that to internal screen settings to avoid
unecessary double tone mapping
reason for 2: I was going crasy because sudenly FF7 Remake had way different
HDR than PS5 or Windows do (seems to be back to 6.2 state after seting to 203
nits). In a nutshell multimidia content is already calibrated to work good with
1000 nits (or cd/m² | candelas per square meter... I'll call nits because it's
screen industry standard caling this way by now). Messing with that is common
sense to not be a good idea. Future KDE calibration screen can and should be
compliant to HGiG and how games access Windows 11 to see the limits of the
screen used. This limits should start with EDID but ultimately be the result of
this calibration process.
reason for 3: I have an OLED C9 from LG. Quite old OLED panel by now. It
suffers from bad SDR processing. I have photosensitive condition thanks to
astigmatism. Still talking about multimidia content: when KDE 6.2 was around I
discovered I could endure countless hours of SDR content just by setting it to
125 or 150 nits. 203 is too bright for SDR content and gives me headaches. KDE
6.3 devoided me from that option and just made things unecessary burocratic.
Consider having this option back an accessibility option that will help people
with my problem. Astigmatism is a very common visual problem justifying the
existence of this.
reason for 4: This is a productivity problem. I think it a consensus that no
one want's to have to look at bright screenwhile working unless the work itself
has to do with multimidia production. That's why the UI brightness must be a
separated setting. Less than 1% of users will actually use the way things are
in 6.3 and beyond as the majority will be looking at code, paper work or sheet
work.
reason for 5: This is a nice setting to have if properly control native
backlight. When this setting can't control native backlight it'll cause havoc
because screen aways remember last backligh level while KDE will adjust output
brightness to even lower brightness causing an issue. As an example this
settings is not able to control OLED Light option from my LG C9 thus making
this option completly useless and potentialy harmfull. This should be disabled
if proper control of native backlight cannot be atained and should not change
image output at all times in that situation leaving actual backlight control to
internal screen settings only. This somewhat remembers me the problem with
Super + P problem. It's not configurable and just works with 2 screens. If one
connects a 3rd it does nothing making the feature half broken.
The must fix section:
1. SDR max brightness slider is misleading as it changes the entire range up
and down from both SDR and HDR causing double tone mapping problems. Also must
not control HDR in any way. Even if this is the intended design it's clearly
the wrong direction to follow based on feedbacks provided until now. Because of
that I'm reopening the issue. Action must be taken either to devoid HDR control
from it or at least change the name and description of what this is doing.
2. SDR and HDR must be separated settings as this is tied to each person's
preference and/or visual issues. (second reason I'm reopening the issue.)
3. Exclusive UI brightness control should be available just to control native
KDE UI for productivity reasons. (3rd reason I'm reopening this issue)
Last, but not least, no reason I described is nonsense and represents real
world usage in other platforms (as another user said here: "KDE don't need to
create another standard for us to deal with 2 standards. Let's just keep what
it works and improve upon that). It has nothing to do with lack of HDR standard
knoledge but I chose to keep language simple regardless to include as much as
possible. More technical people can do the link. KDE don't need to reinvent the
wheels again and should just implement what is already working (like it was in
6.2. That version just need to incorporate new options without losing the
existing ones)
I hope this is useful for devs to know what users expect and want from HDR on
KDE.
--
You are receiving this mail because:
You are watching all bug changes.
