Since I saw dynamic brush in Corel Painter, I have been willing to get something similar to Krita. Basically, it's a paint op which gives the user control over all the parameters (size, orientation, colors etc) of the brush, depending on the input (pressure, time...), the information used for controlling those parameters are what I call "programs". More simple paint op as you can find in current stable version of Krita offers a much more limited selection of parameters.

There is something else I want to provide with the dynamic paintop, until now, Krita's paint op are using what we call potatoes stamps, for each stroke, some sort of mask is put on front of the canvas, and the color is updated according to the transparency, that works pretty well to simulate a pen, or a single bristle, but not a realistic paintbrush. So something, I am playing with in the dynamic paintop is simulation of bristles.

Krita support scripts (in python and ruby) since 1.5 thanks to kross, but one things that was really missing (beside performance) was tighter integration with Krita, I mean, in 1.5/1.6, there is a docker with a list of scripts, and you click and it does 'something', but what I want is the ability to write filters, tools or anything else like in C++ but in Ruby (or in python if you really have to). The anything else part is mostly done if you use some Qt4 bindings, for instance it's already possible to write a new docker in Ruby/Python and it will behave like a C++ plugin (I should try to write a color selector in ruby just for the fun of it). And now, it's possible to write a filter which will appear like any other filter in Krita's filter menu.

At the end of last week, I have released version 0.5 of Kalculus, my front-end to some mathematical tools.

The new version includes quiet a lot of improvements, notably support for octave and gsl (through the ruby binding), an help browser and the possibility to add comment in the calculation sheet.

For those interesting, you can download it from

I have still trouble to feel at ease with KDE4 development, and fill the need to develop against a stable environment, so from time to time I do go back to Krita 1.6 and play with it and fill again my energy bar which I can then spend on Krita2. So last week I did wrote two filters (and I am still working on two others).

Faster Gaussian Blur
Bluring has always been one of the slowest operation in Krita (especially compared to what competitors do), mostly because of my laziness and, also, because for some reason the convolution code in Krita refused to work with non-square kernel (for absolutely no good reason). So, when I wrote the filter, I wrote it as a one pass filter, with one huge kernel, which means that for a bluring of 10 pixels radius, Krita was making 441 memory access and mathematical operations, while with a two pass blur filter, only 42 memory access and mathematical operations are needed, thus reducing the cost by a factor of ten, and the needed computation time as well.

Krita-plugins is now available for downloading here. It includes a slightly improved version of the red-eyer removal tool, and three new filters.

Included new plugins

Deskew
This filter is useful for people who scan a lot of text, as often the text will not appears well aligned.

It a port from a Karl Chen's deskew gimp plugin.

Image Complete

"Image Complete" is a filter which attempt to reconstruct a part of the image which doesn't exist. For instance, in the example bellow, there are some text written in the sky, you just select the text, and then launch the filter, and the text is replaced by a good approximation of what could have been below it:

At LGM, even if it's a not a big conference, at some point, you always need to split yourself in two or three.

Designer using Open Source software
The second day started by a talk by two designers coming from Belgium who made the choice to start a design agency which would only free software. Those guys seems to live on a different planet (well maybe there is three planets, one for designer, one for geeks and one for normal people), they show us some of their creation, I was a bit sleepy (and considering the number of people in the room, I guess nearly everybody else was sleeping elsewhere ;) ), but what stroke me most is that apparently, they have some "creative" session where they try various things, even reverse engineering coca.

I was suggested during last Libre Graphics Meeting edition, that Open Raster should use XMP for it metadata (XMP is the metadata specification that rules them all, exif, iptc... your own metatada specification as well). But until very recently, both the specification and the library were available under a very dubious license which was incompatible with GPL (and with a Open Formats). But Adobe did hear to our complaint, and decided to release under BSD. So, now nothing prevent a wider use in the Open Source world, and that's really cool.

So thanks to Adobe, and if you want to play w

Lets start this blog entry by the first artwork I did with the upcoming Krita 2:

And I must say, the developement version is really starting to be in a good shape, there are still a lot of annoying bug, but it only crashed once, which for a development version, which is still more than six month away of its release, is quiet amazing.

Then, back to the subject, I must say that this year edition of Libre Graphics Meeting was again a major success, and I am happy that I was able to attend it.

This is just a quick update of the ongoing LGM2 in Montreal. Some last minute complications prevented all the Scribus team members from being here, but LGM2 has been an excellent meet so far. In brief:We have announced the latest release of 1.3.3.9, 1.3.4 and the first public demo of 1.3.5, the port of Scribus [...]

I have been making some progress on image adjustment, I am now able to estimate the distortion parameter and to correctly position the images:

The main problem I got was that I was trying to estimate the distortion parameters with two different set, one for the first image, and one for the second. The goal was to be the most general as possible, in case some one wants to create an image with pictures taken with different lens (or with a different focal distance), but it's definitively not the most common use case, so it probably don't fit in Krita's use case for panorama creation.