(Artists check this out) On the project to make a robust mixing texturing brush engine

[JL VT]

Given the time in the year and reminded by our IRC meeting, and a recent
thread in the mailing list, I think this is a good moment to start a
discussion about the incoming work I plan to do for a mixing brush engine.

In accordance to this diagram,
http://www.christopherrichards.com/articles/slow-down-get-smart-2.html
I'd like to introduce a bit of the ideas and concepts I have already
explored and then expose the missing bits.
I am not very good at the fast zone, but that's something I'm working on
since I don't like carrying my flaws all over life and thinking they're just
part of myself. On the other hand, all of my life I have been in the "slow
zone", incubating ideas, solving problems theoretically. And since this is a
project to make a mixbrush to make many users happy and not just myself, I
need to incorporate your requests early in the process to have time to
"incubate, recycle, reiterate and reprocess" all those ideas along with
mine, otherwise I will have difficulty incorporating late additions.


*Some story first* *(SKIP THIS PART if you have no time to read much text,
hop to the "Feedback" section):*

Since some of our artists mentioned in the forums a need for a good mixing
brush, I knew I was not alone in my desire; I too wanted one at least as
good as the Gimp Painter.
I've iterated over the idea several times, every time with a little more
knowledge of programming and with a little more refined idea for an
algorithm that could create the effects I was seeking. It is related not
only to the way colors mix, but also to the after effects intended to give
the brush a characteristic look.
When we mix colors in real life, every media has its own quirks: some mix
like stacking layers of color with little intermixing (pastel in my
experience does this) or nearly none (some crayons); while others completely
diffuse the colors, some more homogeneously (oils) than others (watercolor).
Digital colors mix differently, but just like their real counterparts, there
are many ways to mix them. One of them, which you surely are familiar with,
is the smudge brush. This brush in particular works by duplicating an area
of color and then stamping it over the path followed by the cursor: every
time it is re-stamped, a little of the color from the canvas is copied to
the brush, and a little from the brush is copied to the canvas. This is only
one of many ways to mix colors.

I have forgotten who was the first person who made a mention or request of a
mixing brush but I found these posts below which were the ones giving me the
first problem to solve: how to simulate watercolors with a digital brush.
I've never painted seriously with watercolors, but I've used them, and if
they are anything like their oil counterparts, then color mixing and
diffusion are at the heart of the technique:
http://forum.kde.org/viewtopic.php?f=138&t=88985 --- suspected first post
mentioning request for mixing brush
http://forum.kde.org/viewtopic.php?f=139&t=89749&p=167698&hilit=Mixing+brush#p167698
--- the watercolor post

Ever since then I've been thinking about the problem, and after many hours
of walking in the park, I arrived at an algorithm that seemed to replicate
the effect of a droplet of pigment spreading over the canvas diluted in
water. It was made only with tools that I knew existed (to avoid the problem
of creating the tools); tools used included the blur filter and copying
colors from one place to another ("blitting"). The blur filter simulated
pigments dissolved in water spreading over the canvas: more blurring would
equal more spreading and dilution.

I needed to decide for a method that enjoyed versatility and speed (I don't
even mention stability as that must be a given); this is usually a huge
labor-intensive task, so I tried to find if other people had already done
all the work for me. Using tools that already existed ensured I would not be
duplicating efforts, and tracing the source of the blur filter's magic I
found a way to mix colors quickly and in many different fashions with only a
small amount of work on my part (since someone else had done all the job
just like I hoped): convolution. Convolution is what the blur filter does to
spread colors, convolution is what we use for emboss, for sharpen, and many
other things. It's a wonderful mathematical concept but we're only
interested in its graphical applications. Graphical applications only use a
special case of convolution: discrete convolution. A good introduction here:
http://manual.gimp.org/en/plug-in-convmatrix.html
http://developer.apple.com/library/mac/#documentation/Performance/Conceptual/vImage/ConvolutionOperations/ConvolutionOperations.html

Discrete convolution of two functions can be computed quickly thanks to the
convolution theorem:
http://en.wikipedia.org/wiki/Convolution_theorem

So as long as we can compute a fourier transform quickly, we can convolve
colors quickly, since digital colors are simply a series of 2D matrixes
containing numbers, which is what this whole discrete convolution thing is
about.
The trick here is that Krita already ships with a wrapper for the Faster
Fourier Transform in the West library, so we can convolve anything we want
and it will happen very fast!.

I found the first problem trying to play with convolution: in Krita, when we
convolve colors, EVERYTHING convolves. This would be fine if images didn't
have a SPECIAL color channel that IS NOT TO BE TREATED LIKE ALL THE OTHERS,
namely the ALPHA TRANSPARENCY channel. The bug is that alpha transparency is
not apropiately considered when convolving, this results in reproducible
bugs like the following:

Make a transparent layer.
Paint with the normal brush with low opacity, use a color distinct from
black (white or yellow for maximum dramatism).
Try to blur the colors.
Enjoy the black smudging.

I deviced a solution to that bug, but I haven't coded it. If someone wants
to solve it, I can give all the theoretical details.

Anyway, all those things I described above are part of my "slow zone"
incubation of ideas. I explore the problem, look at it from many angles,
find solutions.

In the next chapter of this wally of texty mailing list series I will tell
you about what method I thought to mix colors similar to watercolors!.


*Feedback*

My plan is to make a robust engine. What I need to discuss is what each
artist expects from the engine. I picture it in my mind as not merely a
simple engine (because everyone here knows that can be done in a few days
using convolution, see previous section), the target is something capable of
imitating what the artists _expect_ the mixing to behave.

David Revoy said he wanted something like watercolors, including pictures of
roughly the desired effect. The more detailed the feedback I get, the better
I can suit the needs for mixing tools.
Think of the code I make as the black box that will fill the space between
input and output, like this:

INPUT -----> Mixing tool -----> OUTPUT

Output needs to be detailed. Similar to Animtim's bug reports where he
describes how the brush behaved and how he expected it to behave given X, Y
or Z input.
I have been working on a mixing mechanism myself (as you saw in the previous
section and will see in the next email) and I've explored the possibilities
already so I am in a good position to estimate how many results I can
squeeze in my time. But the first phase is ideas!, Brainstorming!, then we
can all choose what goes in the "final" version   :-)

Artists, now it's time to voice your requests!, preferably with pictures of
your desired results.

Remember this brush engine is not just about mixing colors but also about
giving the final mixed result a special look, something resembling your
favorite traditional media or something you think would be very useful.


Thank you for reading, and excuse me for typos or errors, despite all the
proofreading I did something is bound to escape.



--- to be continued (another day) ---
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20110105/366665cc/attachment-0001.htm