Bug 245130 - Smudge brush doesn't mix alpha channel
Summary: Smudge brush doesn't mix alpha channel
Alias: None
Product: krita
Classification: Applications
Component: Brush engines (show other bugs)
Version: git master (please specify the git hash!)
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: LukasT
: 258410 (view as bug list)
Depends on:
Reported: 2010-07-19 14:29 UTC by animtim
Modified: 2011-05-18 14:49 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:

Smudge behavior (current and desired comparison) (49.70 KB, image/png)
2010-09-14 21:05 UTC, animtim
Smudge brush size/pressure issue (47.68 KB, image/png)
2010-10-01 13:49 UTC, animtim

Note You need to log in before you can comment on or make changes to this bug.
Description animtim 2010-07-19 14:29:03 UTC
Version:           svn trunk (using KDE 4.4.2) 
OS:                Linux

When using the smudge brush on transparent colors, it set alpha to 1 where you smudge.

Reproducible: Always

Steps to Reproduce:
On a transparent layer, draw something with low opacity.
Use the smudge brush on it.

Actual Results:  
The smudged area becomes fully opaque.

Expected Results:  
Transparency/alpha channel should be mixed with colors.
Comment 1 LukasT 2010-09-14 19:11:07 UTC
SVN commit 1175304 by lukast:

Fixing the mixing of the transparent pixels in COPY mode.

Use new KoCompositeOpCopy2 in the colorspaces.
Remove the KoCompositeOpCopy from the abstract colorspace which is the base class
for the colorspaces.

Leave the old composite copy around, it is still used in KoCtlColorSpace.


 M  +1 -2      KoColorSpaceAbstract.h  
 M  +2 -0      compositeops/KoCompositeOps.h  

WebSVN link: http://websvn.kde.org/?view=rev&revision=1175304
Comment 2 LukasT 2010-09-14 19:14:28 UTC
Animtim: please can you test it now? You need to paint with COPY composite mode.
Comment 3 animtim 2010-09-14 19:28:45 UTC
Ok I'll test it right now!
Comment 4 animtim 2010-09-14 20:40:27 UTC
Nice try, except it adds extra transparency.
For example if smudging on a 100% opaque area (without drawing on transparent area around) the smudged zone shouldn't become transparent.

The smudge should get the Alpha value where you start to draw (as it gets the color value) and mix it with the alpha value of the zone you smudge on (as it mix the color).
Comment 5 animtim 2010-09-14 20:48:57 UTC
Another way to explain:
When smudging a color on a white background, the result is a gradient from color to white.

When smudging a color on a transparent background, the result should be a gradient but from color to transparent.
Comment 6 animtim 2010-09-14 21:05:45 UTC
Created attachment 51647 [details]
Smudge behavior (current and desired comparison)
Comment 7 animtim 2010-09-14 21:08:04 UTC
(On the attachment above the example is with a 50% transparent red square)
Comment 8 Cyrille Berger 2010-10-01 09:27:17 UTC
SVN commit 1181467 by berger:

Fix: smudge add extra transparency

Remains to be fixed, the mixing of black colors.

CCBUG: 245130

 M  +7 -18     kis_smudgeop.cpp  

WebSVN link: http://websvn.kde.org/?view=rev&revision=1181467
Comment 9 animtim 2010-10-01 13:49:05 UTC
It's much better with this fix!

With a mouse there's no problem,
but with a tablet stylus there's still some extra-transparency added just at the begining of the stroke. This happens with Pressure mapped to Size parameter
(I've tried with only Opacity and Rate mapped to pressure there's no problem).

Look at the file attached "SmudgeBugSizePressure.png" to see this bug.
Comment 10 animtim 2010-10-01 13:49:54 UTC
Created attachment 52145 [details]
Smudge brush size/pressure issue
Comment 11 pentalis 2010-10-16 04:15:44 UTC
Summary of the problems left, as per Boud's request:

Note - all problems listed below can only be detected when the size of the brush dab grows mid-stroke. Explanation at bottom.

1.- When strokes are done with the smudge op, with size mapped to pressure, and the NORMAL composite op, BLACK is mixed with the image colors, even if there was no black in there.
2.- When strokes are done with the smudge op, with size mapped to pressure, and the COPY composite op, TRANSPARENCY is mixed with the image colors, causing them to reduce in opacity, even if the image colors were fully opaque before the stroke.

Explanation of the issues: the reason that they happen is that with the current algorithm, when the dab grows, information is requested outside the boundaries of the formerly "absorbed" colors. A small rectangle is first extracted when the stroke begins, but then a large rectangle requested when the dab grows, and as a result the large rectangle is filled with information that wasn't taken from the picture but from elsewhere.
My hypothesis is that this "elsewhere" is simply a default (0,0,0,0) pixel, this explains the strange mixing of black with the former colors or of transparency when the copy composite op is used.
Comment 12 Halla Rempt 2010-10-16 09:15:18 UTC
Yes, that sounds logical. So we would have to scale the original source with the dab size, I guess.
Comment 13 Halla Rempt 2010-12-11 12:24:39 UTC
*** Bug 258410 has been marked as a duplicate of this bug. ***
Comment 14 Halla Rempt 2010-12-14 07:37:05 UTC
SVN commit 1206290 by rempt:

Uncheck the pressure size option by default for smudge


 M  +3 -1      kis_smudgeop_settings_widget.cpp  

WebSVN link: http://websvn.kde.org/?view=rev&revision=1206290
Comment 15 animtim 2011-05-18 14:49:11 UTC
I think we can remove this one as the new color smudge do respect alpha now.