This is an obscure bug concerning the color pickers when using blending (blend < 100%) on a freshly opened instance of Krita. If the first thing you do when started a new document in a new Krita session is attempt to pick a color with blending enabled, the hue of your selected color will jump over to red (hue = 0?) regardless of where it was before and what color you picked. This only happens the first time you pick a color after starting Krita, and only happens if blending is <100% in the color selector tool options. This bug also won't happen at all if the user changes their current color before attempting to pick. I would guess that the issue has to do with the users of the pick color function attempting to retrieve the current foreground color on a freshly opened instance of Krita - something is causing the "canvas()->resourceManager()->foregroundColor();" to return red at the very start of the program and this behavior changes as soon as foregroundColor changes once. It's obscure and just a minor annoyance. Assigning myself to fix it at some point in the near future.
I see similar issues, but for me the color chosen is always black. If I adjust the blend slider to 100% and then pick a color, blending will work correctly once I change the blend back. I suspect it has to do with mapping the slider value to the [variable] which is used to actually compute the blend. If I had a clue where this is done in the codebase, I'd be happy to try and track it down.
Git commit 189679b7108a99f6d15234c7e7738407c0b0f9ee by Emmet O'Neill. Committed on 09/10/2018 at 19:12. Pushed by emmetoneill into branch 'master'. Avoid blending bug on first color pick. In a newly opened Krita instance, the starting foreground color is always in a 16-bit RGBA16 format, regardless of the color space of newly created/opened Krita document. As such, using the color picker's blending feature (which mixes a newly picked color with the user's previous color) immediately after the program starts results in an incorrect or undefined output color. This bug mitigates the problem and fixes the bug request by simply restricting to "pure" (without radius or blending) picking on the first use. M +8 -0 libs/ui/tool/kis_tool_utils.cpp https://commits.kde.org/krita/189679b7108a99f6d15234c7e7738407c0b0f9ee
Fixed for now, though the better solution is probably to make sure that the initial color is in the proper format.
Git commit 38e8b09351cf1bfab37495ba96c8c227605bf3dd by Boudewijn Rempt, on behalf of Emmet O'Neill. Committed on 10/10/2018 at 07:44. Pushed by rempt into branch 'krita/4.1'. Avoid blending bug on first color pick. In a newly opened Krita instance, the starting foreground color is always in a 16-bit RGBA16 format, regardless of the color space of newly created/opened Krita document. As such, using the color picker's blending feature (which mixes a newly picked color with the user's previous color) immediately after the program starts results in an incorrect or undefined output color. This bug mitigates the problem and fixes the bug request by simply restricting to "pure" (without radius or blending) picking on the first use. (cherry picked from commit 189679b7108a99f6d15234c7e7738407c0b0f9ee) M +8 -0 libs/ui/tool/kis_tool_utils.cpp https://commits.kde.org/krita/38e8b09351cf1bfab37495ba96c8c227605bf3dd