Fading Memories

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.

Emanuele Tamponi (Thrain) has managed to implement Kubelka-Monk color mixing for Krita's mixer palette. This means, simply put, that mixing works like in real life. It uses the reflectancy of pigments to reliably mix color on the computer and get the results you've been taught in primary school.

This is really unique. There is no other software available that does this. Corel Painter doesn't do this. Photoshop doesn't do this. There are some academic experiments that do this -- but it's impossible to get the code or the binaries for that.

Hip hip for Emanuele!

(Pics will follow when I've either compiled Krita (I broke my tree) or have finished moving house, whichever comes first.)

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.

Krita's scaled 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:

Gimp:

And now blown up to 800 percent:

The generic code:

Michael Thaler's quality optimized code:

Gimp:

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 is quite extensible. You can add new filters, of course, and chunks of user interface like scaling dialogs, and new tools — like weird and wonderful selection 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.