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.
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. CCBUG:245130 CCBUG:217124 M +1 -2 KoColorSpaceAbstract.h M +2 -0 compositeops/KoCompositeOps.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1175304
Animtim: please can you test it now? You need to paint with COPY composite mode.
Ok I'll test it right now!
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).
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.
Created attachment 51647 [details] Smudge behavior (current and desired comparison)
(On the attachment above the example is with a 50% transparent red square)
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
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.
Created attachment 52145 [details] Smudge brush size/pressure issue
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.
Yes, that sounds logical. So we would have to scale the original source with the dab size, I guess.
*** Bug 258410 has been marked as a duplicate of this bug. ***
SVN commit 1206290 by rempt: Uncheck the pressure size option by default for smudge CCBUG:245130 M +3 -1 kis_smudgeop_settings_widget.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1206290
I think we can remove this one as the new color smudge do respect alpha now.