https://bugs.kde.org/show_bug.cgi?id=509114
Bartosz Taudul <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #17 from Bartosz Taudul <[email protected]> --- (In reply to Zamundaaa from comment #14) > Hmm, so it doesn't set any HDR metadata at all (or it's filtered out by Mesa > for being too bad). This makes KWin assume a 10000 nits peak, which results > in pretty aggressive tone mapping. Can you elaborate on how an application would be supposed to communicate the peak brightness? In my image viewer (https://github.com/wolfpld/moderncore) I basically create a 10 bit PQ Vulkan swapchain, and that's it. PQ max brightness by definition is 10k nits, so that's probably what kwin is seeing, but it is not what my application is showing, as the images you load will have varying max luminances. In kwin 6.3 the brightness you set the pixel at was the brightness seen on the screen, and all was fine (except for highlights, but that was largely acceptable). With kwin 6.4+ and tone mapper in action there's no way to get that back. I could probably correct for this by remapping the loaded image max brightness to account for the 10k tonemapper, but that would mean a test image (https://alexfry.github.io/ACES_ODT_Candidates_Examples/imagesDiagnostic/PQ_100_to_10000nits.avif) suddenly maxes out at 100k+ nits, and how do you even encode that, it's obviously wrong to do so. > I'm not sure what to do about that, the protocol defaults the max luminance > to the maximum of the transfer function. Maybe the protocol needs to be > changed, or Mesa needs to assume some default for when the app doesn't set > anything at all. My suggestion would be to give the user an option to disable the tone mapper, with the resulting 1:1 representation of the luminance levels on the monitor. -- You are receiving this mail because: You are watching all bug changes.
