[krita] [Bug 322839] Brush engine antialiasing

[Dmitry Kazakov]

https://bugs.kde.org/show_bug.cgi?id=322839

Dmitry Kazakov <dimula73-***@public.gmane.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEEDSINFO
CC| |dimula73-***@public.gmane.org
Resolution|--- |WAITINGFORINFO

--- Comment #1 from Dmitry Kazakov <dimula73-***@public.gmane.org> ---
Hi, Odysseas!

Do you mean the line with small diameters has hard pixelated edges or you mean
that the line moves in zigzag'ish way?

The second bug might be already fixed in master. Tomorrow in the morning Krita
Lime PPA (Raring *only*) will be updated up to current master, where the huge
refactoring for the brush engine has happened. If you have Kubuntu Raring,
could you also check this?

PS:
Note, Precise and Quantal versions of the repository will *not* be updated due
to technical reasons :(

[Odysseas]

https://bugs.kde.org/show_bug.cgi?id=322839

--- Comment #2 from Odysseas <xb_creations-/***@public.gmane.org> ---
Hi Dimitry,

I am talking about the pixelated edges in small diameters. I spent quite some
time trying to figure this out in Krita and testing in other software to see
how their brush engines work. I consider photoshop to have the most smooth
performance and brush system, and here is an interesting thing I observed:
Photoshop uses also a default "round" brush tip which can be squeezed or
softened. I tried to see how it behaves in small diameters, so I created a
brush with 100% hardness and no smoothing.
I painted some lines with constant size and some with size controlled by stylus
pressure.

As you will see in the link, the constant diameter stroke is quite pixelated
with diameter 1, probably less than krita though. Bigger diameters are nice and
smooth.
Now the interesting part: When I set the size on pressure, the small diameters
(1-2 px probably) get automatically "smoothed". I think that in this size the
stroke is less opaque, and maybe with softer edges. If the stroke exceeds the
threshold size of 1-2 pixels, it gets fully opaque and smooth.
See the link to understand better what I am talking about.

I tried to create something similar in Krita, tweaking the tip softness and
combining softness and low opacity set on pressure. It works quite well in
small diameters. Increasing the size with these settings produces a soft brush
with low opacity when pressing lightly, so one needs two or more brushes to
achive the smooth look of the photoshop example.

I have installed the lime version in Kubuntu 13.04. I am quite new in linux,
but when I last updated some days ago I saw the word "Raring" in the update
description so I guess I 'll be able to get this one as well. If I am utterly
confused about this I apologise, let me know please!

Good to know about the update, I can't wait to see the improvements. Thank you
for all the hard work!!

[Odysseas]

https://bugs.kde.org/show_bug.cgi?id=322839

--- Comment #3 from Odysseas <xb_creations-/***@public.gmane.org> ---
Created attachment 81611
--> https://bugs.kde.org/attachment.cgi?id=81611&action=edit
Small brush diameter in Photoshop

Example of the way Photoshop handles small brush diameteres.
Opacity is 100%, hardness 100%
The first 2 have constant size, the others pressure controlled size. The
numbers at the bottom indicate the brush size.

[Boudewijn Rempt]

https://bugs.kde.org/show_bug.cgi?id=322839

Boudewijn Rempt <boud-4ZnIdb/***@public.gmane.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDSINFO |UNCONFIRMED
CC| |boud-4ZnIdb/***@public.gmane.org
Resolution|WAITINGFORINFO |---

--- Comment #4 from Boudewijn Rempt <boud-4ZnIdb/***@public.gmane.org> ---
Thanks for the extra info.

[wolthera]

https://bugs.kde.org/show_bug.cgi?id=322839

wolthera <griffinvalley-***@public.gmane.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |griffinvalley-***@public.gmane.org

--- Comment #5 from wolthera <griffinvalley-***@public.gmane.org> ---
I can sort of confirm this bug, and I can also tell you all open-source
software have this issue. I myself always do some trickery with the
hardness-options and the pressure to get this consistent on a preset.

However, there is one open source brush-engine which does seem to behave
properly: The ink tool in Gimp. I suspect it does some kind of vector-trickery
though, and it has no hardness-parameter.

I think photoshop(and a plethora of japanese software) somehow manages to have
the hardness set as a sort of 'absolute' softness instead of proportional,
starting from the edge going inwards. This would make 1 pixel brushes with this
method semi-transparent, even if the opacity is 100%(and unaffected by other
parameters but this softness)

/just a theory

I would set this to a wish, because while it's expected behaviour, and
intuitive behaviour, it is not a mistake in the implementation of the system.

[Boudewijn Rempt]

https://bugs.kde.org/show_bug.cgi?id=322839

--- Comment #6 from Boudewijn Rempt <boud-4ZnIdb/***@public.gmane.org> ---
It looks to me then as if the Photoshop brush engine replaces the stroke
after it's ended with a rasterized vector stroke. I.e., instead of using
the image produced by the accumulated dabs, it re-renders the stroke using
a vector tool and then rasterizes that. If true, it might be visible when
doing a stroke in photoshop, with ragged edges visible while painting
and those getting smoothed out when done with a stroke.

Krita, if you compile Karbon, also has a vector calligraphy tool with
smoothing -- that should have the same properties as gimp's.

[wolthera]

https://bugs.kde.org/show_bug.cgi?id=322839

--- Comment #7 from wolthera <griffinvalley-***@public.gmane.org> ---
Unfortunatly, this is probably not the case.

Photoshop does know 'spacing', 'flow', 'jitter' and textured dabs, all
hallmarks of a dab-based brush system.

[Dmitry Kazakov]

https://bugs.kde.org/show_bug.cgi?id=322839

--- Comment #8 from Dmitry Kazakov <dimula73-***@public.gmane.org> ---
Probably, Photoshop changes the fading curve with the size of the brush...

Wolthera, could you experiment with the curve of the 'Soft Brush' engine and
try to get the brush of a smaller size with the look exactly as you want? Is it
possible at least? If yes, then we should probably experiment with the formulas
we use in the mask calculation thing.

[wolthera]

https://bugs.kde.org/show_bug.cgi?id=322839

--- Comment #9 from wolthera <griffinvalley-***@public.gmane.org> ---
Created attachment 84648
--> https://bugs.kde.org/attachment.cgi?id=84648&action=edit
Attempt at making perfectly maintaining softness-brush.

Oh, uhm, both me and Animtim have made attempts at it, and a variety is part of
the standard brushes(As inking brushes), though a couple of mine aren't and can
be found in the resources forum('inking brushes for Krita')

That said, I attempted making one just now. It uses not only the
softness->pressure, but also some opacity->pressure and a little
spacing->pressure.
The hardest challenge is getting the very tiny sizes (10<, and especially 1<)
render as something else than a fully opaque black pixel, which is why the
spacing and opacity are used.
Spacing for making sure the dabs don't clutter the softness out of each other
by being stacked, and opacity for those tiny sub-pixel sizes.

It's fairly similar to gimps ink-tool now. Though my judgement is horrible.
/spent an hour trying to determine whether the anti-aliasing was perfect or not

_<

[wolthera]

https://bugs.kde.org/show_bug.cgi?id=322839

--- Comment #10 from wolthera <griffinvalley-***@public.gmane.org> ---
Created attachment 84649
--> https://bugs.kde.org/attachment.cgi?id=84649&action=edit
Very large attempt at the same.

Of course, it is ruined as it is resizes, so here's an attempt that's about 5
times bigger, but doesn't have the 1< lines as nice(I turned off transparency
because I couldn't get the required fine-tuning done within the ui)

[a***@public.gmane.org]

https://bugs.kde.org/show_bug.cgi?id=322839

animtim-***@public.gmane.org changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |animtim-***@public.gmane.org

--- Comment #13 from animtim-***@public.gmane.org ---
My opinion on this issue is that we could have a new brush engine like the ink
tool in gimp that produce size-independant nice anti-aliasing for line work.

I think the way pixel brush works now is useful too and shouldn't be replaced,
and so adding this to a new specific brush engine may be easier to code and
easier to use than adding some more options to current pixel brush.

[Paul Geraskin]

https://bugs.kde.org/show_bug.cgi?id=322839

--- Comment #14 from Paul Geraskin <paulgeraskin-***@public.gmane.org> ---
Hello AnimTim.
I disagreed with you. This is a big bug. PS and gimp works ok for resized
brushes. So it must be fixed.

[Paul Geraskin]

https://bugs.kde.org/show_bug.cgi?id=322839

--- Comment #15 from Paul Geraskin <paulgeraskin-***@public.gmane.org> ---
I did another test o proove the issue:

I did a clipboard brush with Spacing=10(Krita) and GimpBrush with
Spacing=5(Gimp).
Loading Image...

Brushes are not scalable at all.

[Boudewijn Rempt]

https://bugs.kde.org/show_bug.cgi?id=322839

--- Comment #16 from Boudewijn Rempt <boud-4ZnIdb/***@public.gmane.org> ---
To me, it almost looks like a rounding error when selecting the next dab size
from the pyramid.

[a***@public.gmane.org]

https://bugs.kde.org/show_bug.cgi?id=322839

--- Comment #17 from animtim-***@public.gmane.org ---
After checking again gimp's brushes, I see they are quite different than
krita's pixel brush, but not really better, more different.

Also it looks like the difference between the "pencil" and the "brush" tools in
gimp.
Looks like our brush engine is more like the pencil tool not adding extra
anti-aliasing (and so allowing pixel-perfect brushes), so we would need a new
mode acting like their brush tool regarding anti-aliasing..

I still think current brush system has a better "natural painting" feel than if
it had always such perfect-linear-anti-alias , which is good in some brush case
of course but gives a more synthetic look.

[Paul Geraskin]

https://bugs.kde.org/show_bug.cgi?id=322839

--- Comment #18 from Paul Geraskin <paulgeraskin-***@public.gmane.org> ---
Ok, Dmitry gave me a patch for AutoBrush. http://pastebin.com/YBF2vJi6

My tests:
With Patch - Loading Image... Loading Image...
----
Without Patch - Loading Image...
Gimp - Loading Image...

BUT THIS IS ONLY FOR AUTOBRUSH! Now autobrush is perfect.

[Dmitry Kazakov]

https://bugs.kde.org/show_bug.cgi?id=322839

--- Comment #20 from Dmitry Kazakov <dimula73-***@public.gmane.org> ---
Just want to add that the patch is only a proof of concept. It shows that the
problem is either of:

- The size of the dab should be a bit bigger than diameter of the brush to
handle aliasing
or/and
- the dab is offset wrongly (?)
or/and
- the spacing of lower sizes should be bigger than usual to get a good quality

all the three theories are not checked yet. And yes, the patch breaks
predefined brush

[wolthera]

https://bugs.kde.org/show_bug.cgi?id=322839

--- Comment #21 from wolthera <griffinvalley-***@public.gmane.org> ---
Okay, confirmed this in IRC, summary of the problem:

What I think is going on is two seperate issues:
1. The current system, when scaling down, has rounding errors. So a soft brush
at size 1 become a black pixel regardless of brush softness.
2. The brush engine softness is PROPORTIONAL. This means that a perceptually
perfectly sharp brush at size 20 looks super soft on size 100. This is NOT
undesirable behaviour, but rather unexpected. (And this same brush would be
almost aliased on size 5).

With my limited programming knowledge, I think 1. is the most difficult one to
solve, but will make a lot of people really happy.
2. shouldn't be difficult to solve, but it's probably an idea to have it as
separate generated brush-tip? Like, we have 'default', 'soft' and 'Gaussian'...
I guess this would be 'absolute' or something? That uses an absolute value
instead of a proportional value for brush softness?

EDIT: Okay, it'll be called auto-brush.
Yes, spacing will also affect the brush. This is due to the dabs overlaying
each other and affecting the softness due to transparencies overlapping.

[Paul Geraskin]

https://bugs.kde.org/show_bug.cgi?id=322839

--- Comment #19 from Paul Geraskin <paulgeraskin-***@public.gmane.org> ---
Boud - Dmitry said you are semi-right :) The issue is in Spacing also. :) So i
hope this bug will be fixed for all brushes in future.
Pixel brush still has issue even with the patch.
Gimp- http://i.imgur.com/yqUpJGS.png
Krita- Loading Image...

Animtim - I again disagreed with you. :) The bug is just a mistake. It will be
fixed in future when Dmitry will have some time.

[Paul Geraskin]

https://bugs.kde.org/show_bug.cgi?id=322839

--- Comment #22 from Paul Geraskin <paulgeraskin-***@public.gmane.org> ---
Hello again.

I did some tests in PS and Krita for Dmitry.

Here is brushes and presets for Krita:
https://dl.dropboxusercontent.com/u/26887202/Krita/krita_antialiasing_test.zip
Just copy everything in Krita and take "round_200px" and "round_autobrush"
presets to test.

Here is comparison:
Loading Image... - the same preset "round_200px" in PS.
Loading Image... - "roud_200px" in Krita.
Loading Image... - "round_autobrush" in Krita.

[Dmitry Kazakov]

https://bugs.kde.org/show_bug.cgi?id=322839

Dmitry Kazakov <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|CONFIRMED |RESOLVED
Latest Commit| |http://commits.kde.org/call
| |igra/b7812a6efe437fd1b8eb95
| |6a399dbd14ea5e3800
Resolution|--- |FIXED

--- Comment #23 from Dmitry Kazakov <***@gmail.com> ---
Git commit b7812a6efe437fd1b8eb956a399dbd14ea5e3800 by Dmitry Kazakov.
Committed on 02/09/2014 at 10:39.
Pushed by dkazakov into branch 'krita-chili-kazakov'.

Remove rounding of the brush scale

It was incorrect to round the brush scale, because it affects the
precision of the line. The bug was not seen in auto brushes, but
it affected Predefined Brushes, since they use the resulting transform
directly.

M +0 -9 krita/libbrush/kis_qimage_pyramid.cpp

http://commits.kde.org/calligra/b7812a6efe437fd1b8eb956a399dbd14ea5e3800