Interview with Krita developers, 2008

Here is the first post-LGM2008 interview. This time it were developers of Krita, the KOffice almighty graphics editor, who dared to cross journalism firing line.

Boudewijn Rempt is a software engineer with a life-long interest in art, linguistics and theology who lives in Deventer, the Netherlands.

Cyrille Berger lives in Toulouse, France. He’s working on a PhD in the robotic and computer vision field. When not coding for Krita, he likes photography (grayscale, silver film), drawing or going out in the mountains for walking or skiing.

Krita’s renewed development started as result of having no good free-as-in-speech painting application, right?

Boudewijn: Yes — sort of. I got a graphics tablet that came with Procreate Painter — a cut-down version of Corel Painter. It wasn’t that good of an application, but it was miles beyond what was available as free software. It got me interested in the topic, and after reading a few academic papers and dissertations I discovered that the Painter approach was quite limited in itself. As is the Photoshop or GIMP approach. So I started to write something on my own, but I quickly decided that it would make sense to join an existing project.

Krita was kind of moribund at the time — it could show multi-layer images, but you couldn’t draw at all. But the Krita maintainer, Patrick Julien was really helpful. I sometimes say it’s him who taught me C++! And by and by I got Krita to a stage where it became interesting. Other people joined in, some — to fix my bugs, others — because they had their own needs for a capable raster graphics application.

Cyrille: We all have various motivation to work on Krita. For instance, Boudewijn is very interested in “painting”, but Casper Boemann joined the team because he needed a 16 bits per channel image editor for a project of a flight simulator he was developing at the time.

These days it really looks like you are trying to focus development on natural media simulation related features. But at the same time you implement functionality that is more geared towards photographers needs like stitching panoramas. How would you describe Krita development’s primary goals in your own words?

Boudewijn: The thing is, Krita is a very flexible foundation for all kinds of image processing. We’ve got an unparalleled architecture to build raster graphics on and a really flexible system of plug-ins. So, where I am mostly interested in creating art, other Krita developers go for the high-end photography features. And that’s fine: one of our plans is to create a system of workspaces where you can have a Krita interface tailored ot your current task.

Some users have found Krita very useful for painting tasks, others have made use of other unique features in free software, like LAB color mode support or painting and retouching on HDR images.

Cyrille: What you say more or less summarizes my own motivation. I have a strong interest in photography, hence the work on stitching panoramas, high-dynamic range imaging, enhancement filters… But I am also interested in drawing which I differentiate from painting, since drawing is more limited to outlines. Therefore I divide my time between those two aspects of Krita.

Thus, to me, Krita is a tool to help you being creative with your images.

During presentation at LGM you demoed a number of applications that dealt with natural media simulation since 70s. But Kubelka-Munk (KM) paper you used for Krita is coming from 1930s. Why do you think it was never used before and not even mentioned a lot in the Internet?

Boudewijn: Oh, it’s been used before, but mostly in the academic world. It started out with Curtiss, Salesin et all, “Computer Generated Watercolor”. Bill Baxter and Tom van Laerhoven have continued in that vein, with, respectively, Dab, Impasto and AquaVerve.

Raph Levien’s Wet Dream watercolor simulation was the first free software application that made use of these principles, to a certain extent. However, Raph intended his work to go into GIMP, but that never happened.

Another problem was that it used to be really hard to go from RGB to KM and back to RGB. Limited and so CPU intensive that research projects often offload the computations to the GPU. But Emanuele Tamponi managed to create a KM color space implementation for Krita that’s both fast to use, even on a modest CPU, and very realistic. I expect his work to appear in many other free software graphics applications.

Hm, maybe you could provide a quick explanation of what exactly Kubelka-Munk’s formula is — for those unaware readers?

Boudewijn: Kubelka and Munk were two scientists who developed a mathematical formula to calculate the reflection of light into a fluid in which metallic pigments are suspended. Much later, scholars like Curtiss and Baxter used their formulas to calculate the effect of mixing color in a natural way — that is, you have so much of this pigment and so much of that pigment suspended, light of a certain colour is hitting that suspension at a certain angle — which presents that colour to the eye. It’s a little bit more complicated than that, of course — but the real complication is that we want to go from ordinary RGB color to KM and back. And there are hundreds of thousands of possibile configurations of pigment and light that can return the same RGB color — and that’s what Emanuele Tamponi has been working on. He has a reasonably reliable roundtrip formula that lets you mix RGB blue and RGB yellow through KM and return a reasonable RGB green.

Have you seen new academic researches related to brush simulation etc. coming to proprietary applications for last several years? Do you follow news regarding proprietary software like Painter or ArtRage at all?

Boudewijn: Yes, I follow their work, as much as possible (I don’t have the money to buy fully licensed versions, so it’s demoware I tend to look at). Painter has a new brush system, called RealBristle that looks a bit like it was inspired by Strassman’s 1986 paper (Strassman S. 1986. Hairy brushes. SIGGRAPH 86). ArtRage is fun to use, but doesn’t go beyond mixing RGB (or possibly CMYK) and using the GPU to simulate paint volume through bumpmapping. The really interesting research work by Bill Baxter and Tom van Laerhoven hasn’t filtered down to commercial applications yet.

Do you think it’s possible to extract simulation code into libraries so that other projects like MyPaint of Gogh could benefit from that or even take part at development?

Boudewijn: Well — perhaps. I’m not sure. MyPaint and Gogh use mostly Python, so any libraries would also have to have Python bindings. But that’s just a technical problem. I think MyPaint and Gogh are more experiments with programmable, flexible brush engines, and Krita can accommodate an infinite number of brush engines. It should be easier, in fact, to make a Kross-based brush engine plug-in for Krita out of the MyPaint and Gogh code than the other way around.

Hmmm, so you see not much of a way to reuse brush engines, but you do see a way to reuse KM colorspace code? How come?

Boudewijn: Colorspace code is mostly just mathematics, easily abstractable. Brush engines are mostly infrastructure, and thus very application specific.

How are you going to deal with three-dimensionality of the real painting while doing simulation?

Boudewijn: For the foreseeable future, we’ll be taking the ArtRage and Painter route here and have a height field that shows up through bumpmapping. There’s only one application (that I’m aware of) that doesn’t take the easy way out, but simulates the true volume of paint, and that’s Bill Baxter’s Impasto. Integrating the ideas from that application in Krita will be hard, so we’ll leave it to the last!

What is exactly difficult about Impasto?

Boudewijn: Krita uses colorspaces to simulate more than color: that is, where colorspace have “fields” for R, G and B or other channels, Krita adds wetness, stickiness and so on. But this is still basically a two-dimensional structure, even though it’s layered and has a Z-order.

But true three-dimensional paint simulation needs an entirely different approach, because real paint isn’t flat. Colour on a computer screen has a height dimension of 0. Of course that height has a visual effect, but more than that: if you paint with thick oil paint, especially when thickened with a filler, you can get three-dimensional structures with peaks and ridges and even some overhang from the peak over the valleys. Simulating that is a tough problem.

What is the largest issue with all current approaches to natural media simulation in all currently existing applications?

Boudewijn: Resolution. For a good painting, you want a high resolution, so you paint fine details, and a large canvas, so you can spread yourself and do complex subjects. But simulation needs to track the state of every pixel and simulation code is slow. Which means that you’re usually limited to low, 512?512 pixel canvases.

Boudewijn, you probably don’t remember that already. Last year in Montreal I asked you how things went with GSoC for you and whether you managed to establish good relationships with your student. You replied that you were very much excited about your student, because Emanuele was already working actively and submitting good code. And it was quite a while before coding time officially started! What about this year?

Boudewijn: This year, because of a relative paucity of slots, we’ve got only one student working on a Krita project. Lukas Tvrdy from Slovakia is writing a Sumi-E brush simulation. He’s taking things like brush hair physics into account, as well as developing a framework where we can use that kind of model in other brush engines.

He’s been is making nice progress, and he’s creating all kinds of weird and wonderful effects, but we’re not yet at the Zen of Sumi-E.

How good is advanced user input devices support? What plans do you have for improving that?

Cyrille: Our tablet support is quiet good, there are some rough edges (in tablet detection for instance), most of the fancy tools like Airbrush pen are not supported — mostly because developers don’t have access to them. And we have support for the more advanced features of tablets (like tilt) in some of our painting operations. We have also made some work on supporting the Space Navigator of 3DConnexion.

Hehe, it looks like Ettore Pasquini contacted most relevant free software projects out there and provided the devices free of charge Which is a smart decision. Did you ever try to establish contacts with hardware vendors like Wacom? I mean, since they already work with linuxwacom developers, they might be same cooperative with you.

Cyrille: Yes, we tried to reach Wacom, but we never had an answer. So we had to resort to a community call, I suppose we can try again once Krita 2.0 is out, especially since it will be available on Windows and Mac OS X.

Having vivid users around who contribute with ideas and examples of real world use is crucial for success of a project. Do you think you have managed to establish a user community already?

Boudewijn: It’s starting to come. I was quite amazed to see so many interesting pieces of art produced with Krita on DeviantArt.

Cyrille: The lack of an organized user community is one of the weakest point of Krita. We have now someone willing to work on KOffice website (which is currently the official website of Krita), and some people who started to work on an independent website for Krita, the goal of both of those sites is to increase the organization of the user community and the visibility of Krita.

Do you have any plans to provide more features for prepress people (like Spot Color Trapping)?

Boudewijn: Not really. I think it’s better to create an image, or set of images, within Krita and then use an application like Scribus to prepare the prepress PDF.

Cyrille: At least, we don’t have a plan against it But I have no idea what “Spot Color Trapping” means, so I don’t have immediate plan for it. But if prepress people want it in Krita, then the first step would be to report it as a wish with an explanation or links on what it is and how they want to use that feature. Then, depending on our todo and the difficulty of the task, it will be implemented sooner or later.

When it comes to collaborative drawing, right now in the free software arena we only have Inkboard (part of Inkscape), DrawPile and some initial code in GEGL/SVN (new “engine” behind GIMP and other applications). Would you want that in Krita as well?

Boudewijn: It would be lovely to have collaborative drawing.

Cyrille: Yes, and work has started for this. But, on a side note, what is in GEGL is local collaborative editing: the main usage is to allow multiple processes to edit an image, then it’s possible to share the file used by the different processes on different computer, but that would require a fast connection between different computers, since you will be transferring buffers.

Cool, then will it be a core KDE technology, a generic KOffice functionality or something purely Krita specific?

Cyrille: A mix of all things together You can even add the Freedesktop layer. So on the Krita level, you have action recording: each time an user does something in Krita, an action of what he did is recorded in memory (well, currently very few actions have been implemented), those actions can be saved in XML which can then be exchanged over the network.

I didn’t know about DrawPile before you mentioned it, but reading through its documentation, it sounds like it is using a similar concept of exchanging actions (instead of part of an image).

It would probably be cool to have some sort of common protocol, but since different applications have different features, it might be very unrealistic to have an action base protocol. It’s even a challenge for a single application, since different users can have different versions, with different plug-ins and different resources)

Well, but resources could be shared for a session, couldn’t they?

Cyrille: Sure, that probably how it will be solved. It’s indeed less of a problem.

You wouldn’t internal versioning of filters help to deal with the other part?

Cyrille:Yeah, but how to deal with this on an user point of view? And the ideal way would be to be able to exchange filters too, but it’s not possible with binary filters.

Anyway, on the KDE/KOffice levels there are some discussions around a library that will handle connections and data exchange (and possibly some functions for text editor, but obviously it won’t apply for Krita ;)). There is a Google Summer of Code to bring collaborative editing to Kate, this project should serve as a basis for this KDE library.

On the Freedesktop level (and also partly, on the KDE level with the Decibel library), there is Telepathy which handles the low level network part (data exchange, Zeroconf to find other users for a collaborative session, etc…).

During last LGM I noticed that while some developers used any chance to go out and talk about things important for their projects you guys were present at most talks, listened attentively and asked sensible questions. I take it as all of you, living in Europe, can meet more often than many others, right?

Boudewijn: Actually, no. We could, but we’re all way too busy with day jobs, university and things like that. IRC and mailing lists are perfectly adequate for discussing design and implementation, and the precious few days we have at an LGM I’d like to spend learning as much as possible, and, indeed, befriend as many people from as many related projects as possible. It’s the human interaction and the breadth of topics at LGM that makes it the most important conference in the year for me.

I know other projects, like Scribus and GIMP, make LGM their annual developer get-together — last year I tried to organize that at KDE’s aKademy, and before that I used to invite all Krita developers to my house in Deventer. And then, our team is really small — if we had a bigger team, a real-life get-together might be more important.

Cyrille: Not really. There has been only one Krita meeting a long time ago, and I couldn’t attend. In the last two years there were two more KOffice meetings to which I couldn’t attend either. So all in all, the only face to face Krita related meeting I have participated was last year at Akademy. And even then we spent more time at the various talks and BOF (Birds of Feather) sessions not directly related to Krita/KOffice ;)). I think the main reason for this is that we mainly come to see what others are doing. We don’t see LGM as an annual Krita meeting unlike some other teams do. But I also think that is why some people ask for a hackathlon to be organized before or after the conference: that way discussions/coding will happen at a different time, and everybody will be able to attend the talks.

What’s your overall impression of this LGM?

Cyrille: LGM is definitively my favorite Linux/Free Software event, so far. A lot of different projects, a lot of different people, speaking about a lot of interesting things related to graphisms. It’s all a good occasion to meet all those people with whom you usually talk on IRC or on mailing list. It’s also a good meeting to put in motion collaboration between projects, such as OpenRaster for instance.

Boudewijn: Oh, man! It’s insane. I just love the LGM. Developers and artists getting together, the wide range of topics, the combination of introductory and in-depth talks, the great atmosphere. It’s also become the venue where innovation is happening. Like Emanuele’s colour stuff, Pablo’s Enfuse, Spiro — I’m sure that before long we’ll want to add an academic track, too.

An academic track?

Boudewijn: There’s a lot of interesting work being done in academia — and that’s totally unrepresented at LGM. At the same time, doing open source is getting more and more a requirement for, for instance, European Commission FP7 projects and it’s getting more and more the norm in academia. So I think that branching out and providing a respectable academic track at LGM would bring in another group of creative people as well as bridging the gap that still exists between the open source volunteer hacker community and academia.

How far are Krita 2.0 and KOffice 2.0 from being ready right now?

Boudewijn: Too far, if you ask me. We’ve got some wonderful innovations lined up, but the problem is that porting to a new platform — and porting from Qt3 to Qt4 is just that — while parts of the platform are in flux is really hard.

Cyrille: There is definitively going to be a release this year. KOffice and Krita 2.0 will enter beta stage by the end of September, early October. While the beta testing time will expand until 2.0 is ready, the release can’t be much longer after that.

Did you ever realize that Krita shamelessly breaks a common stereotype about role and functionality of an image editor in an office suite?

Boudewijn: Oh yes. We’ve even started a separate website for the artist people who feel soiled by using something associated with an office suite. But there it is: I feel KOffice is a suite of applications for creative people, and Krita fits in that. More power to the users, I say!

Cyrille: Yes. And while it’s has good point, since we get the text engine and SVG capabilities in Krita, and in the opposite it brings to KWord the full power of image processing, the main use case would be someone editing a document including images, he would then be able to retouch that picture without launching an external program. But, it also raise some marketing issues, as you said, it breaks a common stereotype, it also means that people interested in graphics application won’t look at KOffice applications for this. This is a problem we are trying to solve, we can with a new suite name called KAtelier which would include Krita and Karbon and be targeted for artists.

You might have noticed how somewhat sentimental people can be about software and hardware. Jimmac not so long ago praised a Wacom Cintiq + ArtRage marriage. Hell, even I sometimes make a joke that anyone who tries to use Inkscape without any bias in no more than five minutes enters nirvana and has his/her Kundalini serpent awaken Do you think it’s normal to have feelings towards something that is basically a hammer?

Boudewijn: Sure. I can wax lyrically about a really good hammer. I mean — I know you didn’t mean it that way, but try to build something with bad tools. If you want to make a nice tree hut for your kids, but your tools suck, you’ll get depressed. And wounded. And your kids will fall out of the tree. A good hammer is worth its price, and you’ll get attached to it. Because if your tool fits your hand, if it lasts, you’ll grow used to it. It becomes an extension of both your body and your mind. And it’s the same with software. It’s a tool — and while good tools cannot replace talent, bad tools can stifle anyone. Good tools are really important and worth fighting caring about.