Created attachment 128937 [details] Screenshot of the incorrect color SUMMARY When painting in a 16 bit color space, after picking a color and rotating the hue with the advanced color selector, the luminosity/value/intensity isn’t preserved and the color gets darker. This is especially noticeable with dark colors. All HSx color modes are affected. STEPS TO REPRODUCE 1. Create a new RGB/Alpha image set to 16 bit integer/channel with sRGB-elle-V2-g10.icc as the profile. 2. Paint some colors (doesn't matter which, but darker colors will be more noticeable) 3. Pick the color with the color picker 4. Click the hue rotate ring in the advanced color selector. Even the smallest rotation should still work. OBSERVED RESULT The luminosity/value/intensity changed (likely darker). EXPECTED RESULT The luminosity/value/intensity should remain unchanged. SOFTWARE/OS VERSIONS Windows: 10 Home 64 bit Krita 4.2.9/4.3.0 beta 1 ADDITIONAL INFORMATION More information, including additional screenshots of the issue, is available in this forum thread: https://krita-artists.org/t/bug-with-advanced-color-selector-hue-in-16-bit-color-space/7557 This issue seems similar to https://bugs.kde.org/show_bug.cgi?id=317648 but not quite the same.
I can confirm this, especially dark oranges put the Advanced Color Selector in a noticeably different state than it should when the color is picked from a 16-bit RGB canvas again (note that you must pick some slightly different color inbetween because it won't update on exactly the same one). Any tweak that makes it set a new foreground color results in a noticeable change of all values of HSV tab of the foreground color dialog. I identified LcmsColorSpace::toQColor() and fromQColor() as the issue. It doesn't use an Elle sRGB profile but the LCMS built-in sRGB (as that's all it can rely on). You would expect them to be equivalent, but I guess Elle Stone spend a good amount of time on well-behaved profiles for a reason, the poorly quantized built-in produces surprisingly large errors, well above just changing an 8-bit component by +/-1, more like -6 to -8 compared to sRGB-elle-V2-srgbtrc.icc. And the reverse transform back to linear RGB doesn't make it better either. Now what's best approach to fix this... Maybe it's time to deprecate KoColorSpace::to/fromQColor(). KisDisplayColorConverter can convert to an Elle sRGB profile itself instead, possibly directly in 32-bit float like the Small Color Selector does.
I would like to add that it is not necessary to touch the color wheel. Directly the advanced color selector where the color is clicked, it selects a more saturated color from where it was selected. The rest of the selectors mark the correct color, even the same docker of the advanced color selector does, if the color was chosen from the advanced color selector of the pop_up. When the used selector is updated (be it the docker or the pop_up), for example, selecting another layer or reopening the pop_up (if this was the one used), the indicator circle will be placed in the correct position. forum thread: https://krita-artists.org/t/bug-with-advanced-color-selector-hue-in-16-bit-color-space/7557
Sorry, this is the thread: https://krita-artists.org/t/advanced-colour-selector-bug/14202/22
Git commit bd50b9667ab5b86ade634982b8a22dc866a505fe by Mathias Wein. Committed on 07/06/2021 at 02:32. Pushed by mwein into branch 'master'. Fix color discrepancies in Advanced Color Selector When picking colors from images with linear color profiles, the color loaded into Advanced Color Selector could differ noticeably. The reason is an optimization performed by LCMS that results in too low precision when the input is a linear color profile. M +8 -2 plugins/color/lcms2engine/LcmsColorSpace.h https://invent.kde.org/graphics/krita/commit/bd50b9667ab5b86ade634982b8a22dc866a505fe