SUMMARY Because of bug 412881 it is nearly impossible (and I don't use this word lightly) to work with Krita's HDR on Yoga c940 without making the brightness of the screen higher. But then the HDR canvas gets brighter as well, showing incorrect colors and artifacts. STEPS TO REPRODUCE 1. Make sure your system is capable of displaying HDR. 2. Open Krita using the lowest brightness of the screen. The interface is dark, but the canvas shows correct colors. 3. Change the brightness of the screen to be higher. OBSERVED RESULT The HDR canvas is getting brighter, shows incorrect colors and artifacts. EXPECTED RESULT The HDR canvas looks the same as before. ADDITIONAL INFORMATION I believe system tells applications like Krita incorrect HDR max value. Maybe there is a way to overwrite this, let the user set the value on their own? It could show the value system tells it, so the user could just check what value it says when the brightness is lowest, and then copy it to the overwriting field so Krita will always use that value instead of whatever system tells it to. SOFTWARE/OS VERSIONS Krita Version: 4.3.0 Languages: pl, en_US, en, pl, en_US, en, pl, en_US, en, pl, en_US, en, pl_PL, pl, en_US, en Hidpi: true Qt Version (compiled): 5.12.8 Version (loaded): 5.12.8 OS Information Build ABI: x86_64-little_endian-llp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: winnt Kernel Version: 10.0.18362 Pretty Productname: Windows 10 (10.0) Product Type: windows Product Version: 10 OpenGL Info Vendor: "Google Inc." Renderer: "ANGLE (Intel(R) Iris(R) Plus Graphics Direct3D11 vs_5_0 ps_5_0)" Version: "OpenGL ES 3.0 (ANGLE 2.1.0.57ea533f79a7)" Shading language: "OpenGL ES GLSL ES 3.00 (ANGLE 2.1.0.57ea533f79a7)" Requested format: QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 10, greenBufferSize 10, blueBufferSize 10, alphaBufferSize 2, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::bt2020PQColorSpace, profile QSurfaceFormat::CompatibilityProfile) Current format: QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 24, redBufferSize 10, greenBufferSize 10, blueBufferSize 10, alphaBufferSize 2, stencilBufferSize 8, samples 0, swapBehavior QSurfaceFormat::DefaultSwapBehavior, swapInterval 0, colorSpace QSurfaceFormat::bt2020PQColorSpace, profile QSurfaceFormat::NoProfile) Version: 3.0 Supports deprecated functions false is OpenGL ES: true QPA OpenGL Detection Info supportsDesktopGL: true supportsAngleD3D11: true isQtPreferAngle: false
Tiar, have you by now looked into this problem? Is the issue still relevant?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!