Krita has got a new website

Krita has got a new website!

After two years and various attempts, Krita finally has a website of its own. And a really nice one, too. Thanks to Krita forum user Kubuntiac who did all the hard work and heavy lifting! Take a sneak peek at — soon we’ll point to the new location!

It’s well integrated within the wider world of KDE websites: we have our forums at, our tutorials go to userbase, developer information will go to techbase and the developer wiki. We’ve got a nice showcase with the most impressive images from the forum gallery. Also, the historical screenshots are back, rescued from the old website.

I promisefaithfully! — that I’ll try to make it a tradition to write a  weekly “Last Week in Krita” entry for the frontpage. It always surprises me  how much we get done in a week. More than seventy commits by seven  people is not to be sneezed at! For now, there’s some nice and uplifting content for you to read!

And… Watch for something really exciting later this week!

Krita 2.1

I was asked the other day whether Krita 2.1 would be an official suitable-for-the-user release. And you know what? That’s actually a very good question. For most of KOffice the answer is easy: no, it is still a developers’ release, by developers, for developers and any adventurous user uses it at their own peril.

But for Krita, it’s harder to decide. Krita 2.1 still has some feature regressions compared to 1.6 (like no image overview docker, some missing filters, among other things I have discussed before).

And the performance of Krita is still quite bad, and we’ve done next to nothing about that for 2.1. I test with a 300dpi A4 image and if I play with layers I can almost make coffee while waiting for the image to be redrawn.

But the stability has improved a lot! We’ve been cleaning away bugs with vim and a hard brush and now there is only one release blocker bug, six crash bugs (only one of which I can reproduce,dash it) and less than forty normal bugs left. Polish is still lacking to some extent, mainly in the area of progress bars, but even there we are making progress.

And subjectively, stability feels pretty good, even while developing. So… It’s not ready for inclusion in the mainstream. But it’s a good replacement for Krita 1.6, if you are not using many of the filters from the krita-plugins package that haven’t yet been ported. So, if anyone wants to give it a try (especially if they are miniature painters who are  satisfied with a 1024×768 canvas), we can use some real-life testing now!

A Vision for Krita

Another long blog post on krita without a single screenshot

The Krita hackers had an irc discussion some time ago on where Krita was headed. With Gimp gaining high-end features that were previously our province (like group layers and an increasingly attractive and polished user interface), and MyPaint becoming a really nice and comfortable paint application (material for another blog!), Krita’s relevance might be thought to have been in jeopardy. And, given that we’ve spent the past three years porting Krita, catching up with the base platforms (Qt, KDE, KOffice-libs) and adding lots and lots of experimental features, it could be argued that we might have lost focus.

So, we first needed to answer some soul-searching questions, like, “what’s the biggest problems we face”, “is it useful or detrimental to be based on KOffice”, “what use-cases do we want to implement”, “what’s better, one big app that can do all, or smaller, focused apps” and even: “Is there still a reason for Krita to exist, given that Gimp is getting more and more polished and has layer groups, and that MyPaint is getting layers and has a dream of a brush engine?”

And there are some seemingly contradictory interests too: developers want to experiment with image manipulation technologies, users want a tool that allows them to make cool art with the minimum of distraction. The interests of photographers, comic book authors, illustration painters and amateur sketchers (that’s me…) are not the same. A tablet pc has only one key: the escape key. An Intuos user has a keyboard and wants a lot of shortcuts. And so. The full discussion is on the mailing list.

Note that all this time, we carried on fixing bugs and improving Krita’s stability! Because, in the end, it’s clear that currently stability is the biggest issue everyone has who tries to work with Krita 2.1. And after stability, performance. We recognize that in our plan: see below.

But first the vision as it appeared from our discussions:


This is what we are thinking now; we are planning a Krita sprint in February and will probably be using some of that time to refine our ideas.

  • Integrated: no endless switching between two apps, but switching between modes of Krita, so no data loss because two apps don’t completely understand each other, not two color selectors or layer modes that have subtly different meaning. So, if you want to manipulate the colors of a layer, switch to the image manipulation mode, and if you want to sketch, switch to the sketching mode. I envision a slider-like widget to do this, not a complex thing like Eclipse, just two or three well-defined gui compositions, ranging from complex to spare.
  • Usable: easy things easy, like getting started with a digital pencil sketch, the rest possible and accessible. We need UI guidelines for things like filter dialogs, tool option panes and brush engine panes. Some things are hard problems, like multiple views, resource management and so on. Our line tool, our assistants really make a diffence for users.
  • Powerful: because we build on the KOffice foundations of pigment and flake (which partly derive from krita, by the way), Krita has got color management, rich text, vector layers and everything. If, in addition to Krita you install more KOffice plugins, an application like Karbon or even, if your tastes lie that way, KChart, you will get more power that nevertheless  doesn’t get in your way.
  • Surprising: Krita offers an unparalleled platform for developer experimentation. Things like Cyrille’s magnetic painting guides or Lukas’ deform paintop are not only unique, but just plain fun, to write and to use. But we need to control the experiments. Right now, we have a lot of half-baked experiments in our code, like Emanuelle’s color mixer. That never got the maintenance it deserved, and I really need to pick it up. We should start working in a way that only the finished, polished feature lands in a release. And we should release often, so there’s no more than two-three months between finishing a feature and releasing it.
  • Accessible: is moribund, the people promising to help with Drupal have all disappeared. points the website, which is rather embryonal. I know that I cannot handle Drupal or wordpress, but what else is there? We need a faq, a gallery, tutorials. Maybe I’ll start with just plain html again… Lukas Tvrdy has set up a number of krita-specific forums on that are proving to be popular. So you don’t need to be an irc-addict to contact us!
  • Hackable: we started with scripting, extended scripting through kross, broke that (will fix it!) and there’s now shiva and its ilk: we want krita to be hackable, even for artists. Procedural layers, filters and brushes, we want make krita hackable beyond traditional scripting in python or scheme, but also beyond the traditional plugins Krita supports (tools, brush engines, filters, generators, file formats, assistants, colorspaces or other extension): if someone wants to add a new layer type that comprises a real node-based system, that’s possible too. But easy user extensibility is our first priority.


A tentative roadmap, where I hope that 2.4 will be released before 2010 is a distant memory:

  • 2.1: stability
  • 2.2: out-and-out performance
  • 2.3: use-case one: bliss out the comic book author whose usecase Enkithan has written down for us.
  • 2.4: use-case two: make something like David Revoy‘s workflow possible in one, integrated application. (Why are all the good artists French?).

And then on and on!

I’ve always thought it a pity that the domain was already taken when I started hacking on Krita. Originally it used to be the abandoned gallery site of some artist; now it’s occupied by a domain squatter. Still, it was taken.

But having a Krita website could very well be a good thing: I’ve frequently heard remarks along the lines that someone either would never have expected a decent graphics app to be hidden in an Office suite, or even from people who flat-out refused to use Krita because it had got office-cooties.

Enter… Wait! Don’t click that link yet! It’s empty…

Someone suggested tacking on the 2d suffix to Krita to show that Krita is about 2d painting — something I liked so much I grabbed the domain. I might even consider renaming the application with the next version. The website is graciously hosted by the same people who host the koffice website.

But getting the domain and asking for hosting is all I have had time for: I’m really looking for a volunteer who can take the material we’ve already got and the texts prepared by Valerie and create a website. I guess any kind of cms or php system can be installed — a wiki with a nice stylesheet and some accounts might be best, even.

So, if you want to help setup the website — please mail me: or join us on the #koffice irc channel (if not afraid of office cooties) or on #krita2d.

Krita and Selections

I’ve made it onto OSNews, just by blogging :-). My webserver seems to be holding up, so let’s add another Krita entry.

Right now the Krita gang is assembled on freenode, #kritaselections, to  discuss the selection system we’re going to design into Krita 2.0. In Krita  1.6, there’s no real distinction between a selection and a mask: selections  are local to layers, and there is no global selection. In a way, this is logical,  because you often use the pixels in a layer (for instance with the magic  wand selection) to create the selection, and because the effects of what you  do with a selection of limited to a single layer — for instance filtering,  copying or transforming.

However, that’s not what users are used to: every raster image application has a global selection. Besides, not being able to selection something on one layer and the use the shape of the selection on another layer is a big limitation. So the question for tonight is: will we keep the per-layer selection, move to a global selection, or combine the two?

And at the same time — how about masks? Technically, a mask is just a selection with an associated filter — most often an alpha transparency filter. Of course, that makes a mask the same thing as an adjustment layer. Again, technically, you’d not even need a separate mask in Krita, just create a group layer with a pixel layer and an adjustment layer on top of the pixel layer. That’s also probably how OpenRaster will save these things — if Oyvind Kolas gets his druthers. If Bart Coppens gets his, they won’t. It’s too early to tell.

As I’m typing, every team member is giving their position, and we’ve also got a Real User, Ronan Zeegers, who creates the icons for our toolbox, to  give his.

Scaling revisited

Krita’s scaling used to be, at least in my memory, a lot better than it’s now. The change came when we went from scaling code that was channel-depth dependent and scaling-specific to channel-depth independent generic  transform code. Today I put the old code back and special cased it for 8 bit rgb, cmyk and grayscale code. Let’s see if it makes any difference. The image was scaled from 1200 pixels width to 400 using the default settings. Just open the dialog, set the width and press enter. That’s what I always
do anyways.

The generic code:

Michael Thaler’s quality optimized code:


And now blown up to 800 percent:

The generic code:

Michael Thaler’s quality optimized code:


The Gimp may still be a little better than Michael’s code, which gives results that are just a little fuzzier, but the quality difference between the generic Krita code and Michael’s code show that my memory hadn’t betrayed me.


As Cyrille says, the people who really, really need CMYK are a limited group. Still, having CMYK is an important thing because it’s the easiest “other” colorspace to implement that still needs icc profiles. (Grayscale is actually quite hard to do correctly, and the very best algorithms to convert to grayscale are horribly patent-encumbered.)

But the real fun starts with L*a*b*. As Photoshop LAB Color: The Canyon  Conundrum and Other Adventures in the Most Powerful Colorspace by Dan Margulis shows, the L*a*b* colorspace really allows for some powerful image editing techniques that are nearly or totally impossible in rgb.

Which is, of course, that I’m inordinately proud that Casper Boemann and me have managed to implement L*a*b* for Krita. You can paint on it, tweak channels and everything. There are limitations: the convolution filters temporarily convert the pixels to rgb and back (fixed in trunk)
and we haven’t got all the filters and dialogs in place that make it easy to use the power of L*a*b* — but that’s something everyone can help with, now the hard work has been done.

Krita plugins

Krita is quite extensible. You can add new filters, of course, and chunks of user interface like scaling dialogs, and new tools — like weird and wonderfulselection tools or a path tool like the one that is right now being worked on for Google’s Summer Of Code. But also new ways for existing tools to paint. I’m working on a Chinese brush simulation based on Clara Chan’s interpretation of Strassman’s Hairy Brushes for Krita 1.6. And finally, you can add complete new colorspaces. We’ve already got various rgb, cmyk and grayscale colorspaces, and also xyz, lab, yuv and lms — but there is no end to the possibilities.

However, the best API is useless without a good tutorial, and I’ve just completed the first draft of Developing Krita Plugins.Apart from
extending Krita with C++ plugins (and, if you manage to get automake and gcj to play ball, java), you can use Krita’s document scripting interface to create scripts in python and ruby. And there’s dcop, too, of course, but that’s not as well documented.

So, if you’ve always thought Krita was nothing more than a glorified icon editor, you can now change that. Go ye therefore, and code all kinds of plugins, extending Krita in weird and wonderful ways, in C++ and Java and Python and Ruby.

ps. What I also wanted to say… Krita’s got a pretty good manual, too, in case you just wanted to use this icon editor.


I’ve been quietly working on a discussion draft for an OpenRaster file format specification. The goal is to create an file format that fits right in with OpenDocument for layered raster images with extras (think adjustment layers). Dave Neary discussed this issue yesterday, which was just the kick in the pants I needed to continue work.

(I’ve been slacking a bit lately. Of course, I needed to work on the last few papers for the theology course I’m nearly done with, and after the 1.5 release Real Life wanted its Boudewijn back for various things, and I got a bit fed up with the kind of reactions that prevail on free software-centered websites lately. But that’s for another rant.) But it’s nice to read that Krita is good, too.

In any case, with the valuable input from Øyvind Kolås (alias Pippin), whose esteemed presence graces the koffice irc channel, I’ve prepared a  discussion piece that after review by Cyrille Berger will be posted forthwith  to the Create project (where we’ve agreed to do the initial discussions) and also be presented to people higher up in the OpenDocument community. The basic idea is to just follow OpenDocument and have a zip archive with XML and binary parts in it.

And then, after lots of discussion of details and lots of coding, we may finally be able to move images from Krita to the Gimp and vice versa  without losing too much.