Archive for December, 2007

Dither in Krita-Plugins

29 December, 2007 Leave a comment

From time to time, there is someone who comes on KOffice channels asking whether it is possible to do something that for a long time we considered to be completely useless in the 21th century : reducing the number of colors of an image. But in fact, there are still a couple of use case. And after some time, I thought it could be fun, especially the palette creation phase, as I got the bright idea to use a genetic algorithm, that’s how you make a 20th century feature, a fun feature to write.

Bellow is the result of the image with an “optimized” palette:

To be strictly honest, I don’t really see much of a difference with a palette created using the most frequent colors of the image.

And because it is totally useless, but yet it was the easiest way to create a palette and do early test of the filter, there is a random generator for the palette:

And as my process to release krita-plugins, and creates packages, is now very smooth and fast, you can find the code and OpenSuSE and KUbuntu packages at


Duplicate or not duplicat, fun and unfun.

20 December, 2007 2 comments

As for all my blog entries, this is my personal opinion about one of my hobbies. And it is neither the official position of the KDE project, KOffice project or Krita project on the subject.

I have been thinking to write that blog entry for a long time, I am often pointed out that I am duplicating effort made somewhere else, while this is sometimes true, this is not always the case, and some other times, it is even intentionally. But giving the reason over and over is really annoying, so now I will simply be pointing to this blog entry.

Four reasons to either develop a new library, subsystem or plug-ins, from scratch, while there are solutions that allready exists and look similar :

1) There is no library that does quiet what you want to do, or not even close to it. When I blogged about color conversion in PigmentCMS, I was pointed out that I should have want to use Babl, which is a color buffer converter, for one thing PigmentCMS is more, CMS usually means Color Management System, but in this case, it also means Color Manipulation System, so PigmentCMS is basically much more than color conversion, it includes all kind of color transformations, that said, Babl could have been used for the color conversion, but in fact, we are already using LCMS for that, and for the color spaces not supported by LCMS, we are going to use CTL (Color Transformation Language). So basically, there was little that Babl was doing, that wasn’t done by other external libraries or some other mean.

We are also often asked why we don’t use GEGL in Krita ? The answer is quiet simple, GEGL didn’t exist when development started again on Krita, in 2004, while GEGL was started around 7 years ago, until recently it was a dead project and when Øyvind Kolås took over, he nearly rewrote everything. So basically, GEGL didn’t exist, and development on both libraries happened at the same time, share some concepts, have some different design decisions, and is developed using two different languages (and agreeing on one would have been an impossible tasks). Besides, there are positive effects to this situation, while it seems a waste of time, because both seems to share the same goal, image manipulation, but there isn’t a higher Truth about it, so by having two competing libraries, two competing pieces of software, we can make different experimentations, discuss it and improves our solutions.

2) License issue. Sometimes, you are interested in a library, but because Krita is pure GPL and rely on some pure GPL libraries, you find sometimes yourself in a position where you can’t legally use a library and distribute your software. The current example I have is the CTL (Color Transform Language) library developed by AMPAS (the organization behind the Oscars ceremony), they are using a derivative of BSD with a jurisdiction clause that makes it impossible for pure-GPL software to use the library (for the disbelieving ones). The two first alternatives is to alter either one licenses, when neither is possible, if you want to use the features provided by the library, the only option, left, is witting an alternative implementation.

3) The library is broken beyond repair, badly documented, rely on bad design, is buggy and use a programming language you dislike (which makes contribution to it nearly impossible). My main example is libexif which is poorly documented, buggy, has an horrible API (worse than most C-library using an object layer) and is not extensible to other meta data specification. If applying the strict rules of no duplicating effort, exiv2 would never have existed. And that would be a shame, as Exiv2 is vastly superior, now in a single API, with a good documentation, one can decode/encode Exif, IPTC and XMP. Implementing Exif support in Krita 1.5 took me more than a week, while replacing it with Exiv2 (and at the same time consolidating in RDF compatible storage) took me twice as less time. So, Exiv2, while duplicating the features of an other library, was clearly not a lost of time.

4) Fun and Knowledge (which are my two main motivation behind my Krita involvement). I am not payed by a company, my whole Krita involvement development is made on my free time, so it has to be fun. And the one single most important thing in the world that deserved our protection, attention and care is Knowledge. There are two parts on acquiring some knowledge, first reading the theory (articles, books, etc…) and second part is practical experiment. Without the first one, you can’t do the second one, but with only the first one, you have achieve strictly nothing, you have no idea of the challenges implied by the theory. In the computing world, the practical experiment is writing code.

Typical example of this is for me is the panorama plug-ins in Krita, I could probably force me into trying to glue the various piece I can found on the web and put them together and voila. On a side note, the alignment library of Krita is flexible enough that you can replace any part or even all part by something else without breaking the features that rely on it. But, I wouldn’t find any fun in doing that, nor would I acquire any interesting knowledge. Besides, unlike what can have been told we are very open to external patches and contributions, so, if someone comes with a patch that does something better than my code, I will happily apply that patch to Krita, and even if that’s mean that my code goes into a black hole, I wouldn’t consider that I have lost my time, after all I have acquired some precious knowledge writing that code.

It’s the fourth point in this blog entry, but it is the most important to me. The first three are driven by the need to achieve something, while this one is driven by the true motivation for open source (you also can have fun and implement something totally new, and I do it too, but that wasn’t the point of this blog entry).

First panorama in Krita

18 December, 2007 4 comments

Getting closer to a release are exiting times, all pieces start to fall together in place. Now is time to time to start finishing the features I have been working on.

I can’t remember when I started working on the panorama plug-in, probably something like a year and half ago. But I barely spend any time on it, except one out of every few months. And this week-end was one of those few time.

Last time I had worked on the panorama plug-in, I had left the code working, but in a pretty bad shape, and nearly all lines of code were assuming that there was only two images in the panorama. So I spend some times adjusting each lines to allow more images, which was very tedious, because one mistake in one line and the process completely fails.

So here is the first full panorama in Krita:

There is still a lot of work to do to reach the use case I have set for Krita’s Panorama Plug-In. But that’s a stimulating result !

And if you are interested in the mathematic behind image stitching, I highly suggest you to read the very good tutorial from Richard Szeliski: Image alignment and stitching (you can find it here : Richard Szeliski’s Publications ).

KOffice and OOXML

12 December, 2007 5 comments

DISCLAIMER: this is a blog entry, this means this is the personnal opinion of the author.

There is a lot of buzz currently around on how KDE and KOffice are blindly rejecting OOXML, and Gnome and Abiword/Gnumeric are blindly embracing it. I think this is a complete misunderstanding, and that the position of both projects isn’t that different, but due to some amplification effects, both position are seen as “extreme” in one or the other direction.

KOffice position is that ODF is and should be supported to be the standard for interoperability between office suite. So, the effort is concentrated on improving the specification, the implementation and ensuring that documents created by KOffice is correctly opened by other Office Suite (and vice-versa). KOffice position concerning OOXML is that, in its current version, it shouldn’t be made an international standard. The main reason is that OOXML isn’t build on pre-existing standard (like ODF for instance, or SVG or even dates…), which result in a huge specification.

But the need of our users is important, it’s very likely that, at some point, we will offer a way to import OOXML, most likely using one of the OOXML to ODF converter. But there is no urgency about this, as currently OOXML is an unfinished specification used by nearly nobody.

My most expected KDE4.0 feature…

9 December, 2007 3 comments

… is a stable development environment.

Tonight I wanted to make a video of a new features of Krita in action, one I had just finished on my desktop. Problem is that my desktop is running OpenSuSE, and xvidcap doesn’t work on it, it just hang. So I have to use my laptop + kubuntu for that kind of stuff. Problems is that after updating it Krita, it comes out that I had to update everything up to kdelibs, and hour and half later, I am still just watching stuff getting build. That’s why, my main wishes for KDE4.0 is that I can, at last, go back to development workflow of 1.x, and have only to update and build KOffice !

Krita-Plugins 1.6.3

9 December, 2007 Leave a comment

I am please to announce the immediate availability of Krita-Plugins 1.6.3.

This new release includes

More information and download (with package for OpenSuSE 10.3 and Kubuntu 7.10) at

Painting in HDR with Krita

1 December, 2007 1 comment

Since Krita 1.5 we are capable to open HDR (High-Dynamic-Range) image and do basic visualization and some manipulation. But, we want to make Krita 2 a fully capable HDR image editor, from creation, manipulation and conversion. For creation, since a while we are capable to create HDR from a bracketing of LDR (Low-Dynamic-Range) photo, for conversion, I have started to add some tonemapping algorithms coming either from last year OpenICC google summer of code or from pfstmo, but that’s a story for an other time.

Today I will speak about painting on an HDR image. While it was theoretically possible to do it in 1.6, it was not possible to select a color outside the normal range. Individual selection of the channel value isn’t intuitive with a classical image, artist use visual mean to select the color. It’s even worse with HDR image, because the value of each channel contains color information as well as amount of light. But the amount of light can be separated from the color information, that’s how we do it in Krita. In fact, as you can see on the video bellow, the user select the “exposure” on the overview docker, then the color in the color selector, and when the user draw the color selected is adjust to the current exposure, that way the color painted correspond precisely to the color selected.

On a side note, that change also allow to select the exposure you want to use when converting back to a classical LDR image for export. And for hardcore users, a color selector based on channel values is probably going to be added latter.