Albanie, Arménie, Bénin, Bulgarie, Burkina Faso, Burundi, Cambodge, Cameroun, Cap Vert, Comores, Congo, Côte d’Ivoire, Djibouti, Egypte, Gabon, Ghana, Guinée, Guinée Bissau, Guinée équatoriale, Laos, Liban, Madagascar, Mali, Maroc, Maurice, Moldavie, Niger, RD Congo, République centrafricaine, Roumanie, Rwanda, Sénégal, Tchad, Togo, Tunisie, Vietnam

So if you are an artist using free software, a developer implicated in a graphic open source project, and want to make a presentation (in either French or English) at the Libre Graphics Meeting, or if you know anyone from those countries, and that would fit the requirements, please read this email or give this email from the Create mailing list. This is a great opportunity to travel to Bruxelles, and meet other people of the Free Graphics World:

But this focus of Krita is not new. What is new is our willingness to focus on it.

Boudewijn has always said that he started on Krita to make a linux application that makes the most use of his newly tablet, he even said at LGM 2007 that he wanted Krita to be a “corel paint killer”. More recently Vera joined us in the hope of helping us to make a good open source painting application.

Personally I started with a joint interest for drawing and photography, and probably considered at first that I wanted to contribute to an application that work for both use. And this would explain why most photographic specific features were written by me. But when I started to make digital pictures, I thought that one of the main interest over silver film was the post-processing, but I have come to realise that colour and brightness adjustment were all the changes I wanted to do, and that otherwise, the pictures need to be shout correctly, correct framing, correct positioning of objects, this require more work in the composition, but this also give greater pictures than cloning. Meaning, that I have mostly used Krita for drawing attempts.

But some other members joined us for photographic interest, and some people would still want to use Krita for those uses, I hope that we manage to work together and allow them to find their place in the Krita Community, either the new extensions website will prove sufficient, maybe a krita-photographic-extension package will be made available by distributions, or it is even possible to build a different user interface on top of Krita libraries.

This is something we are ready to help with, but what we feel is important is that when a painter starts Krita, he get all what he needs, and nothing more.

Qt has caught an exception thrown from an event handler. Throwing exceptions from an event handler is not supported in Qt. You must reimplement QApplication::notify() and catch all exceptions there. terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc

In other situations, std::bad_alloc is replaced by the name of the exception. The problem is that if you now want to know where it happens in your program, the backtrace points to where the exception is rethrown by Qt’s event loop, which is not where the error happens.

I first had this problem a few days ago when implementing multi-layers support in EXR, since the exception name was specific to OpenEXR, I just grepped the code and deduce where the error occurred. But this is not very convenient when the error is generic, like std::bad_alloc which can be thrown just anywhere. And as it turned out by Qt itself in ‘qBadAlloc()’. The solution suggested by Maelcum on IRC is simply to set a breakpoint in the function __cxa_throw, which is a function of the C++ standard library that is actually doing the job when the keyword throw is used (at least with the GNU stdlib++, no idea if it is valid with other standard library implementation). And then you get a backtrace that point to the problem.

I thought I would share this tip in case, in some day, you find yourself with an uncaught exception in a Qt application.

On Tuesday, after work, I went to his apartment. First he showed me a bit what he needs, especially in a patch to the Gimp that brings much needed feature for him, like the brush that mix its current colour with the content of the layer, or the flow setting (that is similar to krita’s “wash” and “build up” modes, except with a fuzzy settings, while Krita is binary). We also discussed the performance issue, especially comparing to Photoshop. Most digital artist would draw their image at a higher resolution than needed, for instance, if you need an image of 1000×1000, then you will draw it at 2000×2000 or even more, which means that you also scale the brush you use, which means that the brush engine needs to be efficient. While more polishing, like more clever shortcuts and easier setting of painting parameters is a must, efficiency is clearly the biggest issue we are facing in Krita, and the one that will need the most work, the good thing is that we already many solutions that will help us to improve that.

Then I installed Krita on his computer (using the ubuntu KOffice backport, I do not know if I missed something, but I found it extremely hard to add the backport to Ubuntu’s software installer). And I showed him the different paint engine of Krita, especially the new one from Lukas, and I talk to him about the goal of Krita, which is clearly focused on digital painting, and image creation. This is where we can have a clear separation between the different 2D graphics application in the open source world, with Gimp having a focus on image manipulation, mypaint being a scratchpad for quickly drawing, and Krita being focused on digital painting. This does not mean there should not be any features overlap, like Krita having a set of filters for image enhancement. It is just that the focus of the user interface and of the development is different.

This led us to discuss on what he can do to help use make Krita the application he would want to use for his artwork. What we need most (a part from more developers ) is testing. While 2.1 is a nice release, it is still far from bugs free, but what is also important is testing of the user interface and of the features, we need to know what is lacking. As a developer, when I draw I tend to bend myself to what Krita can do, while it should be the opposite, it is up to the application to fit the work flow. We already have two artists running the development version of Krita, but more is always welcome to get more diverse opinions.

We also talked on funding development of open source software, one area where the Blender Foundation is very successful is to make movies with Blender, this is very good for advertising the product, since you can show awesome end-results. But it is also very good since developers and artists are working together on the movie, the developers fixing bugs and adding needed features, while the artists provide feedback. The Krita pledgie is one step in that direction. David was thinking that targeting windows users could boost the fundraiser campaign, as apparently many artists are having remorse on pirating proprietary software and might be interested in helping a cheaper alternative, but it is clearly not the primary focus of Lukas work, first we have to make Krita ready on Unix, then other platforms will come.

We have also decided to experiment with a shorter release schedule for 2.3, which is likely to happen four months after 2.2. This will be made possible with the use of Git, and if we manage to keep the release branch in a releasable state at all time, meaning no tests failures, and that features are only merged when finished.

The topic of the meeting is mostly about finalizing the KOffice libraries, with API reviews with Qt Developers, probably some bug fixing and unit testing. As well as a few “administrative” discussion, like release schedules.

While 2.0 was clearly a developer release for developer, and for testing. For 2.1, we concentrated on fixing bugs, fixing some of the annoying issues, 2.1 is coming with many improvements in the MS Office filters, but 2.1 is still lacking in many area, for instance 2.1 comes with experimental support for displaying tables and formulas, but there is no support for editing them. Also there are still many rough edge in the UI. But the progress from 2.0 are astonishing, helped by the good base libraries (Qt, KDE and koffice), external help (Kevin Otten’s student and now Nokia).

While, in general, KOffice 2.1 is still not recommended for end-users. There are two exceptions, the first one is Karbon, while far to be feature full, is starting to become a very capable vector drawing editor, in 2.1 it get support for filters (only blur in 2.1, more is coming for 2.2). I personally use it a lot these days to create illustration for my thesis work. And Krita has made big progress in stability, with dozens of crash fixes for 2.1, and also include many of the new fun painting operation from Lukas, improvement in brush dynamic, recording of filters to create macro…

But using an abstraction of file formats did not give us enough control on how the files are loaded and saved, so four years ago, we decided to have our own implementation of the most used file formats: png, jpeg and tiff. Then later, tired of having to adjust our code for each releases of ImageMagick, we turned to GraphicsMagick, a fork that claim to have API stability. But the long term plan has always being to remove the dependency, and to have our own implementation of the file formats (or to use libraries when relevant).

Things have been accelerated recently, when we discovered that recent version of GraphicsMagick crashes Krita in a very weird way, so we decide to remove the GraphicsMagick files filter, and to finish implementing the format ourselves. This has started with the PPM filter that was finished yesterday, and now I am taking care of the JPEG 2000 format using the OpenJpeg library. But this might mean that in the near future, some important file format such as Photoshop‘s PSD or Gimp‘s XCF will not be available (but there is a Gimp plug-in to export to ORA which can then be imported in Krita).

And of course, since the technology is shared, you add shapes to other KOffice application in the same way. To add a text in Krita ? Go to the add shape docker, drag and drop, and enjoy ! To add an image to your presentation in KPresenter ? Go to the add shape docker, drag and drop, and enjoy ! To add a smiley to KWord… you get it !

Today, I will speak about generators. Since Krita 2.0, there is a special kind of layers in Krita: generators, it’s like a normal layer, except that the pixel are generated automatically. In 2.0, the only generator available was a plain color generator. In 2.1, you can write your generator using the Shiva language.


kernel Singleball
{
const float radius = 0.1;
const float ringradius = 0.05;
const float ycenter = 0.5;
const float ycenter = 0.5;
const float2 center = { IMAGE_WIDTH * xcenter, IMAGE_HEIGHT * ycenter };
dependent float pxradius, pxringradius;
void evaluateDependents()
{
int image_size = min(IMAGE_WIDTH, IMAGE_HEIGHT);
pxradius = radius * image_size;
pxringradius = ringradius * image_size;
}
void evaluatePixel(out pixel4 result)
{
float2 vec = result.coord - center;
float angle = atan2( vec.x, vec.y);
float r = length(vec);
if(r (pxradius + pxringradius))
{
result = outsidecolor;
} else {
float v = (r - pxradius) / pxringradius;
result = (1.0 - v) * ballcolor + v * outsidecolor;
}
}
region generated()
{
region reg = { 0, 0, IMAGE_WIDTH, IMAGE_HEIGHT};
return reg;
}
}

The value of the input pixel is computed in evaluatePixel, while evaluateDependents is used to initialize some constants.

The actual version of this kernel can be found here, the full version contains configurable options for the center and radius.

Then to use your generator in krita you just need to copy it to ~/.kde/share/apps/krita/shiva/kernels. As you can see, I have made a metaball generators, integrated in krita, with its option widget: