Category: Open Source


Krita’s Hackfest, meeting with the Blender guys

Filed Under: KDE, Krita, Open Source
Mar.05, 2010

During this week, Boudewijn is hosting Sven, Lukas and me for a Krita hackfest, dedicated to bug fixing, performance, UI improvement. Among the major improvements brought by that week are improvement in the memory consumption, thanks to a collaboration between Dmitry and me, where I did some tracking and experimentation, and he found the actual problem. This fixed has allowed us to go from 2 minutes of drawing to exhaust my 2GB of memory, to make it possible to paint for more than 30 minutes, there are still some issues that need to be found and fixed. In the area of performance, Lukas have improve the performance of the flood fill by 60%, and I have reduced the time needed for some gradients by six (the other types did not seem to have the problem), unfortunately those improvements are not really visible, for some reason Krita currently spend a lot of time recompositing the image. While Boudewijn and Sven have been working on a scratchpad, as a new way to test new brushes settings, and working on a widget to input value that should be simpler when used with tablets, after Boudewijn’s call for help someone else has offered to help us with that.

Yesterday we went to Amsterdam to meet the Blender’s guys. Since most of us has never been to Amsterdam before, Boudewijn took us for a long walk in Amsterdam’s street (or should I say canal), which started in the overcrowded area around the central station, that we left as soon as possible to walk in more quieter area:

Then at the end of the walk we arrived at the Blender institute:

Where Ton took us on a visit of the Studio, and then we assisted to their weekly update, where all the members of team show what they have been working on, their difficulties and how to solve them. After the meeting, we went to a restaurant, as an opportunity to know each other, and to learn more on how their work, and in hope that one day Krita can be useful for them.

Tomorrow, I will go back home in Göteborg.

Tags: , , ,
read more

The difficult choice of removing features

Filed Under: KDE, Open Source
Mar.02, 2010

Adding a new feature is usually considered easy in the open source world, and then it is taken for granted. Removing a feature, on the other hand, it is a different story. It is not about making Krita less useful, au contraire, it is about making the best for our vision. But why remove a feature, they don’t disturb, or take too much space. They still come in the way and clutter, and what is the point of a menu entry, if you are never going to use it ?

Krita is now focused on being a painting application

We have mentioned in our blogs entry (by me in Krita meeting 2010 – day 1 and by Boudewijn Rempt’s blog) on last week-end Krita meeting, that we had now decided for a vision oriented toward painting.

Where does that leave photography ? Well clearly, it is out. And honestly, between Gimp (especially with their work on 2.8) and Digikam, there is not really much room for an other linux photography application to prosper. Since Krita was always more oriented toward drawing and painting, and photographic features were available mostly because “we can”, and there is no high-end application for drawing and painting on linux, the logical conclusion, for us, was to focus on where we can be the best, and the most useful.

Removing photographic-specific features

The logical conclusion is to remove the features that are not useful for painting. This include many of the photographic plug-ins, like tonemapping, bracketingto-hdr, lens correction, noise reduction filters. As well as a set of artistic filters, but that are mostly useful to transform a picture in something that looks like a painting.

And anyway there are better tool for that job, like the excellent Qtpfsgui, in action below on Deventer’s mill:



I started a discussion on the subject on Krita’s mailing list, which triggered a bit of a uproar. Especially from people who have used Krita for photographic editing. Live with it, use Gimp or Digikam, or install the removed plugins from the future extension website, write your own, just do not count on us for that, we are going to be focused on other features.

An extension website

Since it would sadden me to kill forever some of those plug-ins, and also while we do not want to support photographic features, or features that are of no interest for painting, we also do not want to prevent people to have or use those features, they will simply not be part of the default distribution. We are going to setup a new website where those extensions will be hosted, hopefully with “nightly” build (more like regular build) to keep them buildable, and synchronized with git/hg, where a tag would trigger a new release automatically. In essence a revival of the krita-plugins project.

Tags: , , ,
read more

Krita Meeting 2010 – Day 2

Filed Under: KDE, Open Source
Mar.01, 2010

Yesterday was the second day of the krita meeting 2010. It was oriented toward technical discussions, and UI design discussions.

In the technical area, I and Dmitry had a long talk on how to improve the filter API, to make it both easier to write effect filters, retain performance and ensure that it is less buggy with respect to selections and masks. In meantime Lukas was teaching Vera how to implement new painting operation, so that she can work on a water color brush engine.

When it came to the UI, we talked about what to do with painting op presets preview, and it was decided that it would be more useful for the user to have a scratchpad where he can make his own testing of the current settings, rather than having a computer generated preview. Boudewijn is now working on implementing exactly that. We also discussed painting presets management, it is going to be very basic for 2.2, with just a list name and a preview (either computer generated or made with the scratchpad). And later we would like to have tags, search by tags.

And between two discussions, we were working on bug fixes, polishing features, etc… All the small details to make Krita an even better application. And now is the hack week, with Boudewijn, Lukas, Sven and me.

Tags: , ,
read more

Krita Meeting 2010 – Day 1

Filed Under: Krita, Open Source
Feb.27, 2010

Today was the first real day of the Meeting, we met again in the basement of the Church to be in a place without any possible distraction, and to discuss the vision of Krita, and what we want Krita to be.

We decided to focus on painting, sketching, comic books and texturing. As well as making an application for high-end painters. The question of how much the digital painting should mimick real-world painting, and based on our experience of watercolor in 1.6 that was so advanced that it would simulate the drying itself, we decided that real world should be an inspiration, but that there is no point to make digital painting exactly like real world, if you want real world, you can just take a real brush and paint. But it does not mean that we should take inspiration in real physics, when it makes sense, like for color mixing.

In the end, it took us more than two hours to define the following vision:


Krita is a KDE program for sketching and painting, offering an end–to–end solution for creating digital painting files from scratch by masters.

Fields of painting that Krita explicitly supports are concept art, creation of comics and textures for rendering.

Modelled on existing real-world painting materials and workflows, Krita supports creative working by getting out of the way and with snappy response.

It does not mean you cannot use Krita for something else, or develop plug-ins that solve a problem that does not fit the vision. But it means that we are going to be focused on implementing that vision, and that the default of the application will be oriented toward that vision. And when we have to make choices, we will look at the vision and see which decision makes more sense for the vision.

After the lunch, we took a digestive walk in Deventer streets:

Then we discussed about finding GSoC ideas, that would help to implement our vision, and concluded that a new transform tool and a good UI to access ressources was the two main ideas we needed. Then everybody went back to his computer, to fix bugs, to discuss UI ideas, and just to make Krita “the best application ever” (Vera’s tm).

Tags: , ,
read more

Krita Meeting 2010 – Day -1

Filed Under: Krita, Open Source
Feb.26, 2010

Today right after breakfast with Lukas and Boudewijn and one of his daughter, we got an electricity cut. So when Dmitry arrived from his hotel, despite heavy rain, we decided to go out for a walk in the city, to discover the charm of the city under rain:

Boudewijn explained us about the past of the city, and also which building was going to be demolished, and what nice house has been replaced by an ugly one. We walked a long many nice streets like this one:

Below is a church that was build by the city inhabitant that were denied access to the cathedral, now it is used as a concert hall:

Then we arrived at the market place, where a krita developer took a picture of a krita developer taking a picture of an other krita developer:

Upon our return to Boudewijn’s house the electricity was not back, but Vera had arrived, so we headed to the nearby Church basement which had electricity but no Internet connection. I first tried to work on making OpenGTL’s API nicer to use, while Lukas worked on importing ABR brush from recent photoshop version with the help of Vera, Dmitry worked on layer stack recomposition, while Boudewijn tried to fix a thread bug that seems to only happen on Vera’s computer.

Now electricity is back in the house, Peter and Sven have arrived, and we are finally connected again, and are planning to go in a pizza restaurant in the evening. And now Adam has arrived too. So we are all there now.

Tags: , ,
read more

Krita Meeting 2010 – Day -2

Filed Under: Krita, Open Source
Feb.25, 2010

After being blocked for three hours at Göteborg’s airport due to bad weather condition with heavy snow fall. I was genuinely impressed by KLM paying us a meal and give us a reduction for the next ticket, which covers almost a quarter of the price of my ticket, while they clearly weren’t at fault on the delay. After we managed to take-off, the remainder of the travel went smoothly. After arriving in Deventer, a cute little town east of Amsterdam, I tried to make good use of N810’s GPS to find my way to Boudewijn’s house, but never got a fixed and had to rely on my orientation sense. Now we are waiting for the arrival of Dmitry and Lukas.

Tags: , , ,
read more

How to find where an exception is emited with Qt ?

Filed Under: KDE, Open Source
Feb.24, 2010

When an exception is thrown and not catched in a Qt application, it get catched by Qt’s event loop, and the following message is displayed in the console:

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.

Tags: , , ,
read more

Discussing Krita, digital painting with David Revoy

Filed Under: Krita, Open Source
Dec.06, 2009

For the next releases of Krita, we decided to pick up a specific artist, with a specific work flow, and to implement and fix the issue that he needs. For 2.2 (and probably 2.3), we have chosen David Revoy who has come recently to fame for his involvement in the durian project of the Blender project. Since he lives in Toulouse, and since I still live in Toulouse for the next two weeks, we felt it was a good opportunity to met and to talk about what is Krita, and to get a feel of what he needs.

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.

Tags: , , ,
read more

KOffice 2.2 Release Schedule

Filed Under: KOffice, Krita, Open Source
Dec.03, 2009

One of the outcome of the meeting in Oslo was to take the final decision on the KOffice 2.2 release schedule. Following the current trend of a six months release schedule, therefor the 2.2 RC1 is planned for April, 27th 2010.

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.

Tags: , , , ,
read more

KOffice Fall Meeting 2009 – Day 2

Filed Under: Krita, Open Source
Nov.29, 2009

People are almost already gone, or are about to leave (myself I am leaving the office in an hour or so). The office is getting empty, the discussion are fading away. But today, started by a presentation from Jos of strigi fame on a metadata project for KWord and KOffice, and a proof of concept implementations of ODF 1.2 metadata, and how to use nepomuk. This trigger a discussion between him and Pierre on a design that could work for change tracking and metadata in the KOffice text library.

The last main topic was about making KOffice ready for end-users. And we decided to define a few use cases with an associated users for each application. And then list the features they need, and what kind of issues they face. While Krita is getting focused on being useful for the artist behind Blender movies. Of course, the biggest challenge is now to find developers resources to implement all this ideas and fixes.

This was the last topic on the general session. Afterward hacking started again, as well as specific discussion between a small group of developers. For instance, the Krita team (or what was left of it after the departure of Dmitry) started a discussion on redesigning our painting operation settings, which are currently a bit messy between GUI elements, and settings used for painting.

And now people are either gone, compiling KOffice on windows or almost asleep.

Tags: , ,
read more
Powered by WordPress. Theme: MyMotion by Cyrille Berger as a modification of Motion by 85ideas.