| Summary: | Some brushes create NAN colors in 16bit floating point | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | wolthera <griffinvalley> |
| Component: | Color models | Assignee: | Krita Bugs <krita-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | halla, joupent, romuluspb |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Nan colours are the pixelly black ones to the right.
This brush creates nan-colours at it's start... |
||
|
Description
wolthera
2015-02-22 00:19:37 UTC
Created attachment 91207 [details]
Nan colours are the pixelly black ones to the right.
Created attachment 91208 [details]
This brush creates nan-colours at it's start...
I was able to go around the problem by using some specific brushes from shadow system: Hatch_cross_small Hatch_diag_fat Hatch_diag_S appear to sane the pixels, tried working in the area again and apparently is all ok Hah, that probably means that the hatch brush uses 8 bit colors internally... Not good! Git commit 2f888b32d70f91a206addaf43a2eea94d1b26909 by Jouni Pentikäinen. Committed on 11/12/2017 at 16:09. Pushed by jounip into branch 'master'. Fix NaN values from hairy brushes A hairy brush with ink deplation enabled for opacity, without weights, would use unitialized data from Bristle::m_inkAmount which would later get converted from double to float. Bristle members are now always initialized, and intermediary values clamped to correct range. M +6 -19 plugins/paintops/hairy/bristle.cpp M +9 -9 plugins/paintops/hairy/bristle.h M +6 -7 plugins/paintops/hairy/hairy_brush.cpp https://commits.kde.org/krita/2f888b32d70f91a206addaf43a2eea94d1b26909 Since there have been no new sightings of this bug, I can only assume the fix to the hairy brushes has resolved it. |