Discussing Krita, digital painting with David Revoy

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.

KOffice 2.2 Release Schedule

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.

KOffice Fall Meeting 2009 – Day 2

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.

KOffice Fall Meeting 2009 – Day 1

Yesterday was the first day of the meeting, we had a lot of discussions going on. It started with the move to git, when, what and how ? We decided for a list blocker, and to do the conversion as soon as this blockers were solve, this include solving some of the issues that KDE face for the conversion.

Then we decided to have the 2.2 release on a six monthes schedule, with a release in May, and to experiment a short 4 monthes schedule for 2.3. To be efficient such a schedule require a move to Git, and the ability to work on different branches and only merge what is ready. The main objection to such a schedule was whether it is not too many releases for end users, the advantage is that we solve the problem of schedules alignment with distributions.

Then we had a presentation from the Nokia guys on their work on an Office viewer for Maemo, what they achieved and what they need to have fixed (just 600 bugs…) to consider it end-user ready. And then we talk on how to integrate their work in the community.

Then we went for sandwiches at the Nokia cafeteria.

We started the afternoon with a discussion on how to improve decision making inside the community. The important thing is that we want to take decisions based on a concensus, which require to have people working on finding a solution instead of defending their current solution. But in the end, if there is still a disagreement, we decided that shared component (library and base plugins) would have three maintainers that take the final decision.

In the afternoon, Olivier Goffart gave a presentation on library design, which is interesting since we are planning to export some of our libraries and offer API/ABI stability.

Then we had hacking times, with people fixing bugs, talking design and other discussing on our library organisation.

Then we were invited by Nokia for a pizza party at a nearby restaurant. And concluded the evening with a Krita meeting in the lobby of the hotel.

KOffice Fall Meeting 2009 – Day 0

So I have arrived in Oslo for the KOffice Sprint. We are gathering in the Trolltech headquarter, currently waiting for people to arrive before going to have dinner in the center. Casual discussions have already started about moving to git, about network issues, graphical user interface, distribution flameware. And also doing some hacking.

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.

KOffice 2.1 is released, how user ready it is ?

Yesterday, we released KOffice 2.1, the first major release in the 2.x cycle. It brings many improvements over 2.0, providing a much more stable and rich full experience, you can read more details in the 2.1 release announcement.

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…

Krita and XCF

Last week, I blogged about the removal of the graphics magick file format filter in Krita, and that it would mean that we need to write directly our own support for many file formats, using low-levels library when relevant and available. And by forcing us to do this work, the support for file formats in 2.2 will rock.

Among the three mostly usefull file formats that were delivered by the gmagick file format filter, there is XCF, the file format of the Gimp. After my blog, pusling (Sune Vuorela of the debian KDE team) reminded me about xcftools, a tool written by Henning Makholm that extract information from XCF files. Despite not being a library, the code to parse XCF files is well seperated from the command line logic, and I imported it in Krita (might be a good idea to turn it into a real library ?).

As mentioned, the previous filter was not really good, we were only able to get the layers, but no masks or no composite information, or opacity, as reported in this bug 106730. And with the xcftools based filter, we can read all that information, making XCF a first class citizen in Krita. There might be some issues with composite ops that behaves differently on some cases between application, but that something that we would need to fix as well.

For the other way around, to import from Krita into the Gimp, the OpenRaster Archiving format would be the way to go.

About other file formats, Boudewijn is already working on PSD support. The last important one is GIF support, which will probably be done using libgif.

Inserting shapes/images in KOffice

A while ago, in a praise of karbon 2.0 I wrote, someone commented on the “lack” of tools in karbon, as opposed to inkscape. And from forum posts, or identi.ca, it seems to cause some confusions. For instance, there is no rectangle or circle tool in karbon. And there will never be. The reason is that for KOffice 2, the tools are meant for user interraction, and for manipulating object in the canvas. Inserting shapes is done through the “Add shape” docker, which allow to manager your collection of customs shapes, as well as standard shapes, you can then just drag and drop the shape, or select a shape and then by clicking and dragging on the canvas you can select the size of the shape like with a tool. Once the shape is on the canvas you can go to the toolbox and start having fun with your shape.

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 !

Shiva generator, krita and metaball

One of the new thing of the upcoming 2.1 release for Krita (among improved stability) is that the OpenGTL library is now even more integrated, which makes it even easier to write cool filters or generators for Krita.

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:

KOffice 2.0.0

After more than three years of development, a total rewrite of KWord, KPresenter and Karbon. Major evolution in KSpread and Krita, to adjust to the new shapes-based framework, the KOffice team has released version 2.0.0 today, which is the first milestone for the KOffice 2 serie. You can read the announcement on koffice.org.

We are aware that this release is far to be perfect, and we still recommand the use of 1.6.3 over 2.0.0, but it open the way to further improvement, first with further bug fixes released in the 2.0.x branch, with three planned maintaince released, about one every month (2.0.x maintenance cycle) and with a 2.1 features release in October (2.1 Release plan).

The main goal of this release is to show the new technologies and user interraction. So we would like to encourage developers to have a look at what they can do as plugins, and to tell us about their experience. And to encourage users to test the new interface and to comments on it.