Hi devs. According to the forum http://forum.kde.org/viewtopic.php?f=139&t=120550 i did some tests. It seems colors really distorted bu the smudge. I tested Smudge_soft preset. You need to use tablet and press not so much on the pen. http://i.imgur.com/iwUAnhX.png http://i.imgur.com/NVwml0i.png https://dl.dropboxusercontent.com/u/26887202/Krita/test_smudge.kra
There was a similar bug I had with the linear colourspace on 8bit. As it was a calculation error there, it might be here as well.
Just a few clarification points and steps to reproduce So there are two problems with smudge brush:- Problem 1 – unwanted edge detection Steps to reproduce: 1. Create new layer (as transparency is a major factor) 2. paint on new layer with airbrush (I used preset Airbrush_pressure) 3. paint along the edge of previous stroke with a soft edged smudge brush (I used preset Bristles_wet) http://postimg.org/image/q8tub5w05/ Problem 2 – colour distortion Steps to reproduce: 1. open any flattened image (mine – http://postimg.org/image/whaazqkz1/) 2. select a smudge brush (I used preset Basic_circle_wet – any smudge preset will 'work', the important point is to reduce smudge length 0.01 and increase colour rate to 1) 3. paint multiple strokes each time (increasing) changing hue, saturation and value. Not only is it impossible to paint over with a lighter colour, problem 1 become more apparent and more problematic. http://postimg.org/image/xterl2nod/ http://postimg.org/image/whaazqkz1/ Notice the colour distortion above the left eye (painted using the preset Mix_smear brush with black – also, smudge length 0.01, colour rate 1) To some extent both problems exist on all the smudge brushes but most apparent in situations with transparency, reduced smudge length and soft edges. I was expecting the 'Colour Smudge Brush' engine to behave like the ordinary pixel brush at 100% opacity when smudge length is at 0 and colour rate at 1.
"I was expecting the 'Colour Smudge Brush' engine to behave like the ordinary pixel brush at 100% opacity when smudge length is at 0 and colour rate at 1." That's unlikely to happen, though we need to look into the other points.
Hi, I think I experienced the same problem. :) The problem can be replicated by the following steps with a Mix_dull preset brush ("Color Smudge Brush" with pressure sensitive "Smudge Length" & "Color Rate" enabled in "Dulling" Smudge mode): 1. Create a new empty layer 2. Paint a stroke with fading ends [img]http://i.imgur.com/vNNb2jq.png[/img] 3. Paint another stroke with a different color over the fading edge of previous stroke [img]http://i.imgur.com/4KZZdh2.png[/img] A strange silhouette of previous stroke then appears. More obvious result can be obtained if the colors of painted stroke and underlying color have larger difference in instensity. Besides painting with "Color Rate" enabled, I have also tried smudging from existing color with "Color Rate" disabled, and I got the same result. [img]http://i.imgur.com/tlMvWs7.png[/img] This strange behavior never happens when blending color at non-transparent area even it is not completely opaque, but always happens at the area with color fading to completely transparent. It seems the opacity blends correctly but the color does not. I tried to proof this by locking the layer's alpha and painting another color over the strange silhouette produced by Color Smudge Brush. The strange silhouette disappeared and smooth shade left. [img]http://i.imgur.com/Vzg1WXJ.png[/img] [img]http://i.imgur.com/2DdH4Sb.png[/img] Though it is not obvious, "Smearing" Smudge mode seems to have the same problem as "Dulling". (Paint with "Color Rate" enabled) [img]http://i.imgur.com/ok8YByQ.png[/img] (Smudge with "Color Rate" disabled) [img]http://i.imgur.com/0GUHdkw.png[/img] (Paint another color over the affected strokes with alpha locked) [img]http://i.imgur.com/vT9qvve.png[/img] [img]http://i.imgur.com/uHp3CHp.png[/img]
Created attachment 86731 [details] testcase Same as 'problem1' outlined in comment 2 about the unwanted edge detection - this time using the default Chalk_brush. I thought I'd share this as its a different brush engine. steps to reproduce: just increase the brush size and lay down strokes making incremental HSV adjustments (in the image, I've used a black stroke and incrementally decreased value to the point the edges disappear) The problem also occurs when using the 'pixel brush' engine (soft edge brushes), but its less obvious.
When using 'mix_dull' preset with black color, some yellow aerials appear: http://wstaw.org/m/2014/06/27/plasma-desktopdC1317.png
Git commit 938d73234450f1d07d78617d6d5154d1de773e61 by Dmitry Kazakov. Committed on 04/12/2014 at 10:54. Pushed by dkazakov into branch 'master'. Fix composite copy to use classical OVER algorithm on semi-transparent data Now when source and destination have non-transparent pixels we use straightforward OVER algorithm that does expected things: 1) Premultiplies src and dst 2) Blends them using opacity and mask 3) Unmultiplies the value to write into the destination This algo is even more complex than the one used in COMPOSIRTE_OVER (yes, we use approximation) and works about 50% slower than OVER. But since most of the time COMPOSITE_COPY is applied without mask the slowdown will be hardly seen. M +72 -23 krita/sdk/tests/stroke_testing_utils.cpp M +19 -1 krita/sdk/tests/stroke_testing_utils.h A +- -- krita/ui/tests/data/Mix_dull.kpp M +3 -0 krita/ui/tests/filter_stroke_test.cpp M +43 -4 krita/ui/tests/freehand_stroke_test.cpp M +1 -0 krita/ui/tests/freehand_stroke_test.h M +8 -0 libs/pigment/KoColorSpaceMaths.h M +31 -8 libs/pigment/compositeops/KoCompositeOpCopy2.h http://commits.kde.org/calligra/938d73234450f1d07d78617d6d5154d1de773e61
Git commit b410a5844bfadc295da78ba8e996060e22b79246 by Dmitry Kazakov. Committed on 04/12/2014 at 10:54. Pushed by dkazakov into branch 'krita-psd-rempt'. Fix composite copy to use classical OVER algorithm on semi-transparent data Now when source and destination have non-transparent pixels we use straightforward OVER algorithm that does expected things: 1) Premultiplies src and dst 2) Blends them using opacity and mask 3) Unmultiplies the value to write into the destination This algo is even more complex than the one used in COMPOSIRTE_OVER (yes, we use approximation) and works about 50% slower than OVER. But since most of the time COMPOSITE_COPY is applied without mask the slowdown will be hardly seen. M +72 -23 krita/sdk/tests/stroke_testing_utils.cpp M +19 -1 krita/sdk/tests/stroke_testing_utils.h A +- -- krita/ui/tests/data/Mix_dull.kpp M +3 -0 krita/ui/tests/filter_stroke_test.cpp M +43 -4 krita/ui/tests/freehand_stroke_test.cpp M +1 -0 krita/ui/tests/freehand_stroke_test.h M +8 -0 libs/pigment/KoColorSpaceMaths.h M +31 -8 libs/pigment/compositeops/KoCompositeOpCopy2.h http://commits.kde.org/calligra/b410a5844bfadc295da78ba8e996060e22b79246