Fading Memories

Krita already had filter plugins: filters take pixels as input and produce possibly different pixels as output. Filters in Krita can be used destructively: to change a layer or a mask directly. They can also be used dynamically: either in adjustment layers that filter the result of the layers under the adjustment layer in the layer stack, or as filter masks, that filter the contents of a single layer. Or you can paint with them, and in the future you can associated filter parameters with the pressure, rotation and other types of input from your input device. I'm working on that...

But now, requested by Matthew Woehlke, there's another type of plugin: generators. Generators take parameters but not pixels as input, and create pixels as output. That's ideal for things like Apophysis-like plugins. Right now you can only use these generators in Krita on paint devices, as fill types (similar to solid colors or patterns) with the fill tool or as dynamic layers. Painting should be possible, too, but that needs some work. And it would be nice to use this kind of noise in a transparency mask or in a filter mask: that's already possible, but not in a dynamic way.

There's just one snag: I'm not a mathematician, so I depend on other people to write nice generator plugins! Matthew has promised to do something Apophysis-like, but we need lots more: flames, clouds, checkers, waves, marbling -- for someone with the right kind of knowledge or no compunction about copying code from other free software, the possibilities are endless!

So today the Wacom Art Pen arrived -- thanks are due to Cornelius Schumacher, Thorsten Zachmann and Eva Brucherseifer and Axel Jäger who busied themselves with paying, ordering, checking, sending on after a misdelivery! The art pen has a very nice feel on the tablet, a kind of resistance that makes drawing a lot of fun. And there appears to be not a single X11 application that makes use of its rotation feature.

To celebrate the new tablet I have started working again on my Chinese brush simulation. I'm working on the research done by Clara Chan. The Krita version works -- somewhat. The lines the brush bristles draw are not anti-aliased. There is some support for tilt, but not for rotation yet -- which would be quite interesting since rotation of the brush is one the ways to get the right effects when painting in the xiao pin style.

Apart from the cool things we can now develop for the tilt and rotation features there is another thing: the koffice input device architecture goes way beyond what other applications do. In an application like Photoshop or Corel Painter there is only one active tool, no matter which input device you pick up. If you paint freehand with your art pen, and then grab the mouse, click the pan tool, then pick up your art pen again, your art pen pans.

Already with Krita 1.6, you can select the pan tool with your mouse and a paint tool with your stylus. To me, this feels like a very natural style of working. If I paint with real oils, I tend to hold the active brush in my left hand, and in my right hand the palette and a quiver of other brushes of different sizes and with dabs of different colors. If I work with pencil or charcoal, I have a stick of charcoal in one hand and an old cloth in my other hand to soften the lines.

With KOffice 2.0, every input device, even every pen you've got for your wacom has its own tool. So, if you've got an airbrush, a stylus and a mouse, your airbrush can be associated with the freehand tool and the airbrush paintop, your stylus with the freehand tool and the chinese brush paintop and your mouse with the pan tool. And if you've got three styluses, each one can be associated with a certain tool or paintop. Without needing to configure stuff, of course, you can just select tool and paintop by clicking on them. We have already implemented this, but testing with different wacom input devices was a bit hard.

What doesn't work because of an unfortunate but fixable design oversight is having different active colors for different input devices: that would be the ultimate (although expensive) analogy to working with real brushes! (We'll also have to persist the state between sessions, too)

Gone are the dialog-bound preview widgets of yesteryear! Yesterday I managed to have a live filter preview in Krita for the first time:

As you can see, it's not perfect. There are some artefacts that suggest that I have an off-by-something error somewhere...

The idea is to have user-definable, draggable area that's filtered by the filter and settings currently selected in the non-modal dialog box you see top-right, automatically updated some time after you made your last change to the settings. Then, when you're satisfied you can selected to either create a live filter mask (which can have any shape, of course), or destructively filter the current layer, which takes into account the selection (of course).

The draggable and resizable part will probably only be done for 2.1; right now I'm already quite deliriously happy that we've gotten this far.

It's been a long slog getting this far: I had hoped to be done in May, but real life (like buying and renovating an old house and getting a new job) interfered. Not to mention bugs, design errors resulting in two redesigns and the occasional priority shift because we needed to refactor selections, redisplay code, the filter api and other stuff just to get here.

But what we've achieved now is pretty cool, even with all the bugs:

We've got a layer stack that can contain paint layers (with a fixed, i.e., dried, and a changeable, i.e, wet, part), group layers, adjustment layers (that act as a filter foil on top of a stack of layers), copy layers (that copy the result of another layer to a new place in the layer tree) or Flake object layers.

All these layers can contain a stack of masks: selections (containing both vector shapes and per-pixel selectedness) that you can paint on and that can control transparency, apply transformations (like rotation or moving), apply any filter or simply indentify selectedness of pixels for a particular layer.

For as long as I can remember, articles on scaling images have been accompanied by proofs of prowess by scaled versions of one particular image of a particular lady, apparently called "Lena", either in black & white or in color. A quick google will bring you hundreds of projects that have one or another version in their repositories. Who started using this image? Where did it come from?

At least it's a fairly tasteful image, not like some of the images the first KImageShop developers used to showcase KImageShop. But to keep in with the wider tradition, I've started to use lena to unittest our prescaled canvas projection code. Which code is giving me considerable trouble...

My new job means using Windows, and that means a laptop with Windows on it. And since I didn't have a linux development machine anymore until yesterday, I tried to compile KOffice on Windows. I managed to compile it all right; running didn't work.

But that's no problem, because Jaroslaw Staniek had me beaten to getting KWord running (albeit without most plugins) and Adrian Page has made Krita run under Windows. In his own words:

Krita's been running on windows for a couple of weeks now, but I never got round to reporting the progress.

So now Krita is truly cross-platform: it runs on X11, OS X and Windows. I hope to get my Linux development system up and running today so I can start fixing the layer/node structure tomorrow & the qpainter redisplay code. To to start making progress again!

It took many iterations, lots of code, lots of mathematics. But in the end, Emanuele Tamponi has succeeded where others have failed miserably: if you use Krita's new paint mixer to mix colors, you will get green from blue and yellow, purple from blue and red and orange from yellow and red.

This is truly an advance of the state of the art. By comparison, the Corel Painter mixer palette degenerates into ugly brown much faster.. Maybe their mixer is still based on simple cmyk addition, as Bill Baxter suspected. Of course, we still need to do work on the wetness-dryness selection UI, add a color picker functionality, a brush clean button and complex blend loading. There's always more to do.

But... Look at that wonderful green!

Oh -- and let's not forget to mention Paolo Capriotti, who helped Emanuele with some of the mathematics.

One of the things that we were really looking forward in Qt 4.2 for Krita was Arthur. I dare say the Gimp developers are in the same situation, only they long for Cairo. Aliased temporarily lines and pseudo transparency are so nineties.

In any case, with Arthur the benefits come almost automatically. Like in this screenshot:

Embarrassingly, I first saved this screenshot as a JPG image and subsequently thought that Krita created artifacts around the anti-aliased line. Er, well, blush...

Other things are easy, too, like transparency checks that stay in place. Since the checkerboard under the image is supposed to represent something fixed like a desk, it stands to reason that the checks should stay put if you scroll the image. The performance of Qt4's Arthur in this area isn't quite as good as Krita 1.6's OpenGL implementation, but it comes close and is officially Good Enough for Me.

This week, by the way, saw a lot of work on Krita: I've started implementing the layers, masks and selections stuff, as well as a begin of the infrastructure that will make it possible to enable and disable channels of a layer for things like filtering, compositing and painting:

The day when Krita's L*a*b mode is finally going to be good enough for the tutorials in the Margulis book is coming close!

Cyrille has reinstated the YcBcr colorspaces (8 and 16 bits, naturally), Sven Langkamp has been working hard on porting our home-grown Undo/Redo system. It's not finished, but Casper Boemann is working on some stuff, too, notably the zoom system, but also an extended curve widget and a nice cross between a combobox and slider.