--===============1750679657== Content-Type: multipart/alternative; boundary=20cf3054a4c59a36c7049922d404 --20cf3054a4c59a36c7049922d404 Content-Type: text/plain; charset=ISO-8859-1 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) --- --20cf3054a4c59a36c7049922d404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Given the time in the year and reminded by our IRC meeting, and a rece= nt thread in the mailing list, I think this is a good moment to start a dis= cussion 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 alrea= dy 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&#= 39;t like carrying my flaws all over life and thinking they're just par= t of myself. On the other hand, all of my life I have been in the "slo= w zone", incubating ideas, solving problems theoretically. And since t= his is a project to make a mixbrush to make many users happy and not just m= yself, I need to incorporate your requests early in the process to have tim= e to "incubate, recycle, reiterate and reprocess" all those ideas= along with mine, otherwise I will have difficulty incorporating late addit= ions.


Some story first (SKIP TH= IS PART if you have no time to read much text, hop to the "Feedback&qu= ot; section):

Since some of our artists mentio= ned 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 littl= e 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 on= ly to the way colors mix, but also to the after effects intended to give th= e 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 exp= erience does this) or nearly none (some crayons); while others completely d= iffuse 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 familia= r 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=A0re-stamped, a little of the color from the canvas is co= pied to the brush, and a little from the brush is copied to the canvas. Thi= s is only one of many ways to mix colors.

I have forgotten who was the first person wh= o 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 wat= ercolors, but I've used them, and if they are anything like their oil c= ounterparts, then color mixing and diffusion are at the heart of the techni= que:
h= ttp://forum.kde.org/viewtopic.php?f=3D138&t=3D88985 --- suspected f= irst post mentioning request for mixing brush
http://forum.kde.org/viewtopic.php?f=3D139&t= =3D89749&p=3D167698&hilit=3DMixing+brush#p167698 =A0--- the wat= ercolor post

Ever since then I've been thinking about the proble= m, and after many hours of walking in the park, I arrived at an algorithm t= hat seemed to replicate the effect of a droplet of pigment spreading over t= he 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 versatilit= y and speed (I don't even mention stability as that must be a given); t= his is usually a huge labor-intensive task, so I tried to find if other peo= ple 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 b= lur filter's magic I found a way to mix colors quickly and in many diff= erent fashions with only a small amount of work on my part (since someone e= lse had done all the job just like I hoped): convolution. Convolution is wh= at the blur filter does to spread colors, convolution is what we use for em= boss, for sharpen, and many other things. It's a wonderful mathematical= concept but we're only interested in its graphical applications. Graph= ical applications only use a special case of convolution: discrete convolut= ion. A good introduction here:
http://m= anual.gimp.org/en/plug-in-convmatrix.html
http://developer.apple.c= om/library/mac/#documentation/Performance/Conceptual/vImage/ConvolutionOper= ations/ConvolutionOperations.html

Discrete convolution of two functions can be computed q= uickly thanks to the convolution theorem:
http://en.wikipedia.org/wiki/Convolut= ion_theorem

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

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

Make a transparent layer.
Paint with the norm= al 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 cod= ed it. If someone wants to solve it, I can give all the theoretical details= .

Anyway, all those things I described above are p= art 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 t= o watercolors!.


Feedback

My plan is to make a robust engine.=A0What I need to di= scuss 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 some= thing capable of imitating what the artists _expect_ the mixing to behave.<= /div>

David Revoy said he wanted something like watercolors, including pictu= res of roughly the desired effect. The more detailed the feedback I get, th= e 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 pr= evious section and will see in the next email) and I've explored the po= ssibilities 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!, t= hen we can all choose what goes in the "final" version =A0 :-) = =A0

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

Rem= ember this brush engine is not just about mixing colors but also about givi= ng the final mixed result a special look, something resembling your favorit= e 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) ---
--20cf3054a4c59a36c7049922d404-- --===============1750679657== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ kimageshop mailing list kimageshop@kde.org https://mail.kde.org/mailman/listinfo/kimageshop --===============1750679657==--