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: krita2d.org is moribund, the people promising to help with Drupal have all disappeared. krita.org points the koffice.org 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 forums.kde.org 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 krita.org 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… krita2d.org. 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 Krita2d.org website — please mail me: boud@valdyas.org 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.

Krita at Fosdem 2006

Irina’s birthday tends to collide with Fosdem, so I probably won’t ever go there. But Bart Coppens went (he’s a local guy, after all) and gave a nice presentation which apparently was very well received.

We’re busy fixing the last-minute bugs in Krita. Tagging has already been delayed a bit, and we’ll probably have to delay some more. It’s not like we’re in deep trouble, but a last minute optimization that made it possible to load a 5000×5000 image in only a few seconds has quite a few repercussions.

Natural Media

Nathan Willis has written a very good article on Krita for linux.com,  Exploring natural media graphics with Krita, where he describes where I personally want to take Krita in the future.

Of course, Krita is and will remain a competent image manipulation  application, with cmyk, lab, adjustment layers and all that jazz, but my core interest is indeed natural media. Which makes me very happy that Bart Coppens has managed to make wet paint usable:

Everything works, except that we should disable parts of the user interface that are not relevant to wet work when the layer is wet and that drying is still a problem. In this image you can also see  Gábor and Casper’s jointly  produced layer preview tooltips.

In other news, the freeze went by, but hacking is still frantic. First  beta’s are notoriously supposed to be unusable, but I do hope people will download the sources, packages and kliks and test KOffice 1.5 beta 1 really thoroughly. Especially OpenDocument interchangeability is of paramount importance, but there are other big improvements that could do with some serious user testing, like all of Krita, really, and big chunks of KWord, KSpread and KChart, and KPlato. We’ve been busy.

I didn’t witness much of the freeze, actually, because I was laid up with acute food poisoning (again…) and I’m still not quite well. Actually, I’m going down about now.