Paris capital of Ruby

Last week I was working in Paris, and only had a borrowed laptop on which I didn’t feel like to go through the pain of setting up a KDE4 development environment. So instead of writing C++ code, I decided to improve my Ruby skill and still be able to hack on something of a certain use for Krita.

While it has been a while since I have started using Ruby, I never really wrote more than a few lines each times. But now, that at work, I finally was able to drop TCL for Ruby, I have made a lot of progress during the last few weeks. But lets go back to a subject related to krita.

So last week I had plenty of time, on the train to go working, to make a lot of progress on a framework (called WaterFlow) for creating flowchart of operations. Am I writing a clone of kivio/visio/dia/whatever ? No, the goal of those applications is to visualize information or data, while the goal of WaterFlow is to visually create programs. My first idea for this was to reuse kivio, but then I considered that it would require more work than creating a light weight visualization engine. Especially considering how easier it is to display and manipulate graphics with the new QGraphicsView framework of Qt4.2.

As you can see bellow, a lot of work remains to do, but I have achieve the basic feature, and currently all you can do is define mathematical operation, for now, it’s just a more complicated to use calculator than kcalc. Except that it support retro-action loops !

But what’s the link with krita ? A lot of image manipulation algorithms are a combination of basic algorithms (like bluring, inverting…). Most of the time, for an user, the layer stack is more than enough to achieve what he wants to do. Lets take two use cases, one when WaterFlow is usefull and one when it’s a burden.

• Arthur has taken a picture of “big ben tower” in London, but while the disposition of the image is good, the image has a lot of qualities issue (noise, sharpness, color, etc…). He wants to create a chain of filters to fix his filter, he needs to be able to adjust the parameters of each filter and their positions in the chain. It’s already to do this, it still needs improvements, especially in the filter side to make more of them work with the system:

  The use of WaterFlow for this task would be a burden.

• Ben likes Krita for its work, but he found that it is a lacking a simple feature he needs a lot, as a professional photograph, he knows the math of the operation, but he don’t know how to program, so he needs a simpler way to create its custom filter. Lets consider “unsharp mask” (which is in fact in Krita since version 1.6, but it’s a simple example), the basic of the operation is to blur the original image and then to mix the original with the blur version, as you can see the layer stack doesn’t allow to create such operations, that’s where WaterFlow can be of use.

  In fact, I don’t think Ben will ever try to use WaterFlow, he will probably have gone back to Photoshop or The Gimp, but at least it’s an useful tool for filter developers to easily try new combination of filters before implementing a faster version in C++.

The next step is to test with Krita 1.6 if WaterFlow is suited for what I want to do with it, and modify it accordingly.

Howto: watercolors

A few weeks ago, I made a blog entry about a watercolor sheep in krita. And someone ask me how to do watercolors in krita ? And I told myself that it would be better to write an howto. A month to answer a question, so good for my willingness to be fast to answer questions 😦 But until a few days ago there was one aspect of watercolors that I didn’t understand. And mostly because it was yet to be used, but now it’s fixed in the incoming 1.6.2 version. So along the cool smudge paint op, there will be a dry filter for water colors.

The basics

To create a water color, at the startup screen of krita, select “custom document”, choose the size (choose a bigger size than the size you want to use, some simple operation like resizing or moving the layer doesn’t work well, while crop works perfectly), and then for the “color space” choose “watercolors”.

Then you get a special color palette with a choice of 14 different color. And two options “Paint strength” and “Wetness”, the former is used to control how much color is dropped on the canvas at each stroke. It’s a little bit similar to the opacity option for classical color spaces.

And “wetness”, it was the parameter I couldn’t understand the use, as it use by the dry filter. The drying is some sort of blurring balanced by the amount of water on the canvas. And the wetness option control how much water is dropped on for each stroke.

The reality as the artist sees it

For the image above I did use different level of wetness. The sky and the soil were drawn with the maximum level of wetness, while the ground and the crock are paint with no wetness. The leaf and the flower are drawn with a low level of wetness.

A video of the action

What better way to explain something that to show it ? Here follow a 5 minutes (and 16 MB) long video, where I draw the flower above. It shows the effect of the “paint strength” option.

It’s definitively not real time, making video hits a lot of cpu, and a lot of frames got skip. Especially when krita became hungry in cpu cycles, during the drying process. Note, that the dying filter is iterative, which means you need to apply a lot of time before getting the end result.

Also note, that watercolor (in 1.6) is an experimental feature, consider it as a demo of what we want to achieve with krita in the future.

Why krita require lcms, qt, kofficelib, etc.. ?

Often I read comments about people wondering why krita require this or that library, and therefor will not work without it. Like in the last dot announcement about koffice 1.6, or in a bug report asking for krita to be separated from koffice.

The three hard requirements of krita are kolibs, qt/kdelibs and lcms. It’s nearly impossible (unless making a local copy of those one in the krita tree) to build krita without any of them. And as I will try demonstrate bellow, we make an extensive use of those libraries.

KoLibs

It’s probably the most hated dependency of krita. “Why is that krita is part of KOffice ? No other Office suite include a bitmap manipulation program !” “Surely there can’t be much in common between a spreadsheet program and krita.” Well that’s true. kspread and krita are probably the two applications of KOffice with the less in common.
“So surely you can’t find a common point between a presentation editor, a word processing and krita ?” Well that’s wrong, both kpresenter and krita are very demanding of a powerful text engine, and kword is able to provide that, for a little work on our side. And further more, the three applications are very demanding of whatever vector graphics can be provided by karbon.

And that’s just small example.KoLib bring us (or will bring us) a filter and shell architecture, a powerful text engine, vector graphics… and much more.

Furthermore everything is not about code, while this blog entry is mostly about it, but being a koffice application allow to share administrative effort: like releasing, webmaster, public relations…

Qt/KDElibs

I also read some comments wondering if a gtk port of Krita is possible (beside the question of the usefulness of the idea), it’s hardly possible, I can’t think of a single file in Krita that doesn’t use a Qt class.I guess some people tends to think that most library are use superficially at the outside border of an application. This is definitively not the case. Qt/KDElibs is a framework, not that we use everything possible, but as soon as something we need is available in the framework, we make sure to use it. So while in our code, we have a clear separation between the image manipulation library and the UI, that doesn’t mean it’s possible to use the image manipulation library without the framework. Qt/KDElibs is definitively not just about GUI, and I think that trolltech has made it very clear that they want Qt4 to be use in non GUI application by clearly splitting Qt4 in different libraries.

lcms

There is more to color management than just displaying the right color on the screen or printing it accurately. It’s a misconception that lcms is only used for those two tasks (beside the fact that printing is not yet correctly implemented). A simple task like brightness/contrast is a color management task. And actually, using the filling tool also use a lcms function (which was the main reason why 1.15 is the minimal requirement for the latest version of krita). In fact, it’s the less needed library of the three, with the current architecture of krita, it’s easy to wipe out lcms, but that would still requirement more than a week of hard work to cripple krita.

But the plugin architecture protect us from most of the requirements

For instance krita is depending on GraphicsMagick (or ImageMagick) for reading various image format, but it’s a weak dependency, if someone doesn’t need the support of those files, then he just don’t build the corresponding plugin. That’s what does Fedora Core, they don’t consider that those file format are worth it, so they don’t ship the plugin.

Krita also support python and ruby scripting, but none of them are needed to run krita.

So when it makes sense, because it doesn’t require a lot of work on our side, or a lot of duplication of an already existing work. Then we make our best effort to have krita independent of that library.