New Patch: Smudge Brush

[Silvio Heinrich]

On 01/10/2011 11:16 PM, JL VT wrote:
> Silvio, I downloaded your patch and added it to a git branch called
>
> krita-fixsmudgebrush-silvioheinrich
>
> It's available in the remote repository (the master) such that others 
> can check it out and play with it.
Oh, that's cool :D


> I noticed a problem with your version of the brush, slightly 
> transparent colors quickly become opaque:
> http://imagebin.org/132048
>
> That doesn't give the impression of smudging very much. This is a 
> problem the old brush had to an extent, but it was mostly about the 
> darkening (with black).
You are right. My smudge brush did build the color up to much/fast.
This was bugging me all the time but it was due to the fact that i only 
copied the opacity
and not the colors too. But now i actually found out why the 
KoCompositeOpCopy class
was mixing the black color into everything and made it work as expected.
Now i use the COMPOSITE_COPY mode and the smudging behaves much better :).


> I am also having difficulty replicating the "look" of the old smudge 
> brush defaults. Can you try to tune the defaults of your new brush to 
> look as identical as possible to the defaults of the old smudge 
> brush?, this will help avoiding unfamiliar behavior.
>
> I also want to ask you why did you remove this part of the code? -->
>
>         // Both limits defined to be 15 units away from the min (0) or 
> max (255) to allow actual mixing of colors
>         const quint8 MIXABLE_UPPER_LIMIT = 240;
>         const quint8 MIXABLE_LOWER_LIMIT = 15;
>
>         /* Without those limits, the smudge brush doesn't smudge 
> anymore, it either makes a single
>         dropplet of color, or drags a frame indefinitely over the 
> canvas. */
>         opacity = qBound(MIXABLE_LOWER_LIMIT, opacity, 
> MIXABLE_UPPER_LIMIT);
>
> Is it because you put the limits in the controls or the GUI, or is it 
> because you deemed it unnecessary?
>
> From my testing, I think it's because you thought it was unnecessary, 
> but I'll show you a case you can test yourself:
>
> http://imagebin.org/132050
> http://imagebin.org/132051
>
> With the old smudge brush, even at max rate, the brush decolorates 
> with time: it looks like a smudge.
> With the new smudge brush (yours), at max rate (and even at 
> intermediate rates as long as you press hard with the tablet), the 
> "smudge" turns literally into a crayon, there's no decoloration, the 
> same shape the brush started with becomes the one it ends with.
> And also at low rate the brush doesn't smudge anything at all.
Well i think the user should be able to choose from min. to max. smudge 
rate.
The absolute minimum is no smudge and the absolute maximum is smudging 
without fading.
But this is of course a matter of taste. We can set the minimum smudge 
rate a bit above zero if you like.
But the maximum smudge rate should stay at 100% because it gives imho 
pretty nice effects
when using 100% smudge rate and turning on the color option.
I mainly removed this because i hate macros (:P) and hadn't introduced 
any limitation functionality yet.
Now you can limit the rates with the PressureRateOption and 
PressureCompositeOption classes.


> I think you need to address that problem, if not with a hardcoded 
> limit, with a tweak to the controls (a tweak to the controls is harder 
> because tablet users also introduce a new factor to watch out for: the 
> curve), or with a logarithmic curve or something, because currently 
> it's very easy to cause this smudge brush to behave nearly like a 
> clone tool (as displayed in my screenshot).
>
>
> Other than that I think your brush is fine for me (I don't know about 
> the rest), since 2.4 is in development I think it would be good if 
> your brush could be added with a new name, for example Smudge 2, such 
> that artists can test it and directly compare it with the old Smudge 
> Brush, they will be the first ones to notice any regression (because 
> regressions are hard to gauge anyway, sometimes what looks like an 
> advancement to someone will look like a regression to somebody else).
>
>
> Here is me hoping to see you around in the near future,
> Thank you for your contributions!
>
>
> On Mon, Jan 3, 2011 at 9:20 PM, Silvio Heinrich <plassy at web.de 
> <mailto:plassy at web.de>> wrote:
>
>     Now it should work pretty similar to the smudge tool in gimp.
>     But I still need to do some tweaks to how the rate values (color
>     and smudge rates) are used.
>     It only smudges/paints correctly in a certain region of the rates.
>     But the transparency issues should be solved by now, so no black
>     color should be introduced anymore (hopefully :P).
>
>     _______________________________________________
>     kimageshop mailing list
>     kimageshop at kde.org <mailto:kimageshop at kde.org>
>     https://mail.kde.org/mailman/listinfo/kimageshop
>
>
>
> _______________________________________________
> kimageshop mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop

So here is the newest version of the smudge brush and i hope there are 
not to many flaws this time.
I made the patch against origin/master. So I Don't know whether it will 
apply correct on the branch or not. Maybe you have to reset the branch
or something? I'm not a git pro :D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20110112/2594edc7/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SmudgeBrushNearlyFinal.patch
Type: text/x-diff
Size: 0 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20110112/2594edc7/attachment-0001.bin