Uhm... so, this is a thing I managed to do... Reproducible: Always Steps to Reproduce: 1. make a 16bit float krita file 2. Use either a) gaussian blur on objects, or b) the brush I will attach. 3. Gaussian blur will result in a black blobby mess that while reported as black, doesn't actually act like black(smudge it)
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.