Patch for smudge

[JL VT]

Answer to LukasT: right next.
Answer to CyrilleB: by the end of the letter

On Thu, Sep 23, 2010 at 4:10 AM, LukasT.dev at gmail.com
<lukast.dev at gmail.com> wrote:
> On Thursday 23 September 2010 07:41:38 JL VT wrote:
>> From a tester's point of view, this change is very cumbersome. Please
>> try to make it such that the "fading time*" of the brush is similar to
>> the previous one, ~50% faster at most. It currently feels like the
>> brush fades more than twice (maybe trice?) as fast as before, and with
>> certain rate settings it basically vanishes instantly.
>
> It is quite complicated problem. Have you got solution or idea how to fix it?

No idea yet, it's certainly quite complicated. I'll be munching an
algorithm during my idle times.

>> I observed artifacts in both cases.
>>
>> Prepatch:
>> --Applying the brush on partly-transparent pixels darkened them too
>> much (consistent with bug report).
>
> Darken is something different. They became opaque, right? Not darken.
> Darken is other composite mode. Or really darken like more black?

Ahh, yes, it became opaque, that's the right word. It didn't become more black.

>> --The stroke starts with white pixels inside the red blot when using
>> the copy composite op, this was bad.
>
>> Postpatch:
>> --Problems persist with the copy composite op, there still are white
>> pixels inside the red blot when the dab resizes mid-stroke (example:
>> using stylus). (Upside: this problem is fixed when using just the
>> mouse).
>
> It actually should add transparency. I'm surprised.
>
>> --New problem with copy composite op: OUTSIDE the red blot, a
>> completely unexpected black smudge appears. This problem is less
>> obvious when using a tablet, but completely obvious with the mouse.
>> --With the normal composite op this works pretty well and as expected.
>
> This is weird problem. We have similar darkening in the deform brush.
> The black smudge does not appear in rgb 16-bit scRgb linear. Maybe some gamma
> correction has to be added for rgb8?
>
> Don't we have some bug in rgb8 colorspace then?

I just tested the brush strokes with RGB16 linear, and the slight gray
tinges of color are still present when stroking with the Copy
composite op (with mouse it is more readily noticeable).

>> The small red square inside the stylus stroke using normal composite
>> op is EXPECTED, this was discussed earlier with Cyrille Berger and
>> there's some comments on the commits (I think I should have documented
>> our discussion). To avoid that artifact, simply reduce the spacing
>> during the stroke.
>
> Ah, I did not know that it was expected. How do you reduce the spacing during
> the stroke?

Oops, that was a really bad choice of words on my part. I simply meant
using a spacing of 0.01~0.05 in brush settings.

>> Trying to make that "artifact" disappear for all cases is very tricky.
>> We went for a compromise that optimizes speed. Also, this is only
>> visible when the dab varies size during a stroke (specially when it
>> grows quickly). Otherwise it is indistinguishable.
>
> Question is if we do not want to throw away the size change for smudge.

It makes us cool for trying to cope with a problem all other
developers try to avoid  (Gimp and Photoshop do not sizechange their
smudge op). In fact I think I just came up with a simple solution:
give the user the option to decide how many dummy runs the brush will
do. By default we're doing 1 dummy run to fill the temporary device,
but by doing 3~7 dummy runs, the problem with the little rectangle
inside (caused by sudden growth of the brush) disappears.
And then for 2.4 I have my version of smudge brush that scales the dab
every time it is resized and thus solves the problem. So let's keep
size change for the sake of coolness.

>> I also spotted a silly BUG related to SELECTING composite ops:
>> --Pick the smudge op.
>> --Pick the copy composite op.
>> --Then switch to the pixel brush using the hotkey approach (right
>> click or middle click of the mouse?).
>> --You'll see that the copy composite op is selected in practice (paint
>> with it), you'll also see that the name of the composite op doesn't
>> appear on the list (it shouldn't be selectable in the first place!).
>
> To http://bugs.kde.org please. Could you look at this boud? Or if busy, put it
> on my Action Plan III.

Done.



On Thursday 23 September 2010, cberger at cberger.net wrote:
>Rereading your patch, I notice you did not exactly followed my suggestion on
>IRC :) To make things clear, I have made a patch that does what I suggested.
>
>It has decent smudging (I didn't compare it with previous code), it smudges
>transparent pixels. But there is a square block bug, when drawing on
>transparent pixels (as can be seen in [1]).
>
>I let you investigate the block stuff :)
>
>[1] http://cyrille.diwi.org/tmp/krita/smudgetest.png

Clever patch!, but it is somewhat equivalent to the old smudge op
behavior, and there's gray/black smudges present too. It still
presents the problems Animtim describes in his bug report:

https://bugs.kde.org/attachment.cgi?id=51647