[krita] [Bug 422267] Advanced color selector hue rotate affects saturation/value in 16 bit color space
https://bugs.kde.org/show_bug.cgi?id=422267 Lynx3d changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED Latest Commit||https://invent.kde.org/grap ||hics/krita/commit/bd50b9667 ||ab5b86ade634982b8a22dc866a5 ||05fe --- Comment #4 from Lynx3d --- 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-2plugins/color/lcms2engine/LcmsColorSpace.h https://invent.kde.org/graphics/krita/commit/bd50b9667ab5b86ade634982b8a22dc866a505fe -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 422267] Advanced color selector hue rotate affects saturation/value in 16 bit color space
https://bugs.kde.org/show_bug.cgi?id=422267 --- Comment #3 from Felix --- Sorry, this is the thread: https://krita-artists.org/t/advanced-colour-selector-bug/14202/22 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 422267] Advanced color selector hue rotate affects saturation/value in 16 bit color space
https://bugs.kde.org/show_bug.cgi?id=422267 Felix changed: What|Removed |Added CC||felgut...@gmail.com --- Comment #2 from Felix --- 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 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 422267] Advanced color selector hue rotate affects saturation/value in 16 bit color space
https://bugs.kde.org/show_bug.cgi?id=422267 Lynx3d changed: What|Removed |Added Status|REPORTED|CONFIRMED CC||lynx.mw+...@gmail.com Ever confirmed|0 |1 --- Comment #1 from Lynx3d --- 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. -- You are receiving this mail because: You are watching all bug changes.
