| Summary: | 4.0.0 and 4.1.0 pre-alpha: Colour Picker fault with 32-bit float colour depths. | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | Ahab Greybeard <ahab.greybeard> |
| Component: | Color models | Assignee: | Dmitry Kazakov <dimula73> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | halla |
| Priority: | NOR | ||
| Version: | nightly build (please specify the git hash!) | ||
| Target Milestone: | --- | ||
| Platform: | Debian stable | ||
| OS: | Linux | ||
| Latest Commit: | https://commits.kde.org/krita/26b61c6bfe0e41bc0cc6a1a8733ae1618144ee82 | Version Fixed In: | |
| Attachments: | Screenshot from 4.1.0 pre-alpha, shows the effect | ||
Also check with Wolthera. Git commit 1e513a176c8a5782c0d518488ef0a085ac22621f by Dmitry Kazakov. Committed on 05/04/2018 at 07:55. Pushed by dkazakov into branch 'master'. We should initialize KoColor object before picking data into it Otherwise memory overflow happens and we start reading/writing weird uninitialized memory chunks. M +2 -4 libs/ui/tool/kis_tool_utils.cpp https://commits.kde.org/krita/1e513a176c8a5782c0d518488ef0a085ac22621f Git commit 26b61c6bfe0e41bc0cc6a1a8733ae1618144ee82 by Dmitry Kazakov. Committed on 07/04/2018 at 13:28. Pushed by dkazakov into branch 'krita/4.0'. We should initialize KoColor object before picking data into it Otherwise memory overflow happens and we start reading/writing weird uninitialized memory chunks. M +2 -4 libs/ui/tool/kis_tool_utils.cpp https://commits.kde.org/krita/26b61c6bfe0e41bc0cc6a1a8733ae1618144ee82 |
Created attachment 111787 [details] Screenshot from 4.1.0 pre-alpha, shows the effect This problem is present in the 4.0.0 and 4.1.0 pre-alpha (b6620443) for 32-bit float colour depth. 16-bit float and other depths do not have this problem. It is not present in the 3.3.3 release. If a new image is created with the default 32-bit floating point colour space, colours can be chosen normally with the 'colour wheel' and the Specific Colour Selector dockers. If the Colour Picker tool is used (using Cntrl-click or the tool from the Toolbox) then the colour wheel shows the correct colour (usually, but see below) but the Specific Colour Selector shows a very transparent colour on its sliders. The resulting brushstroke is of the chosen colour but with miscoloured parts. The attachment shows a full screenshot taken from the 4.1.0 pre-alpha. The colour for each upper line for each colour was selected using the colour wheel. The lower line was selected using the colour picker tool. Note that the blue colour, when picked from, gives a green result and this green was also shown in the colour wheel appearance at the time. All coloured lines show patches of miscolouring. The Specific Colour Selctor indicates transparency. The colour picker does not show a coloured square after picking (or maybe it shows a transparent square). With the 4.0.0 appimage, the painted line (using the colour picker) is usually transparent but sometimes is of a different colour with large gaps in the painted stroke. The mitigation for this is to not use the colour picker but to use the colour wheel or the Specific Colour Selector.