Archive for July, 2008

Darkroom 1.1

25 July, 2008 2 comments

Since I got postitive feedbacks about Darkroom, and my interest for RAW images has pick-up while playing with my camera. My interest for developing further Darkroom has considerabely increase. And I guess it’s an other example of how much good technologies like Qt and kdelibs allow to easily build up new GUI applications, in a very limited time. For instance, in this new release, everything is multithreaded, using the threadweaver library, which manages queues and threads for me (the only thing it could do better might be status reporting, or I need to figure out how we can get usefull status information). Now Darkroom also comes with a file view, instead of just allowing to go from one image to the next one in a directory, and you can apply the current settings to a bunch of images and then go take a cup of coffee (or two if you have a lot of images to process). And last but not least, you can adjust exposure, and it get some basic color management facilities.

You can get it from my website.


Darkroom 1.0 and Import Raw in Krita

20 July, 2008 10 comments

It all started on Friday when I had a look at the pictures I took in Berlin, during the KDE-Bindings meeting and on my way to the airport in the city center. I found them incredibly noisy, my digital camera is starting to age, it’s more than four years old, so I was wondering if it wouldn’t be a good idea to replace it. At first, I had decided to wait a little bit before buying a DSLR, but seeing how poorly hand-held camera still behave, yay they have more mega-pixels, but why is it useful if the results is completely noisy and blurry ? And you can’t tell yourself that you will buy one of the low mega-pixels camera, since they also have crap results, since they sell their product on the number of mega-pixels, no manufacturer will take the time of making a good hand-held camera, sad. So I turned myself to a DSLR (help with the fact that price have considerably dropped recently).

Since new babies are introduces with a picture:

I didn’t had time to use it much, but I still spend sometime yesterday afternoon taking pictures in Toulouse, but I already like it a lot, since I was able to concentrate on just taking pictures instead of spending time adjusting options, while still having the possibility to adjust them for extreme situation. Which is good, I am so used to take picture with a silver film, entry level camera Nikon F60, where the only things you can do is adjust the speed and aperture, which is about all you usually need.

Here is a view of the Capitole:

Darkroom 1.0

Back to the point, KDE applications, since that’s probably all you want to hear about. One of the usual feature of DSLR camera is the possibility to save pictures as RAW file, which is basically a dump of the sensor output to memory. To be precise, there is no such things as a RAW file format, there are about hundred of them, for each camera manufacturer, model and sensors.

Now that I have a camera with RAW, I want proper support for it in Krita and in my KDE environment. Especially that I was stupid enough to shot around 20 pictures as RAW files while I just wanted to have one or two for testing.

On unix, the main application to decode RAW files in something useful is dcraw. In the KDE side we have libkdcraw, which offers a front-end to a stable dcraw version (yes one of the bad side of dcraw is that it is not a library, but a command line tool whose option changes all the time) and a configuration widget. Using that library I told myself it would be easy to write a KDE based RAW decoder. Yes, I know there are already quiet a few of them, but Darkroom is like 400 lines of code, since all the logic is either in dcraw or in libkdcraw which is shared among KDE applications.

A few hours later, here is the result:

You can get it from my website if you want to play with it. I am not to sure about its future, one things is certain, I don’t want to invest much time in Darkroom, maybe on libkdcraw, or of course Krita, which would bring back improvements to Darkroom.

Import RAW in Krita

The next logical things to do is to get an importer for RAW in Krita, actually there was one in Krita 1.6, but did I mentioned that interfacing with dcraw sucked ? Well, that means the Krita RAW importer start stopping working and there was no one who had time to fix it and maintaining, that’s where using libkdcraw will help us, since the maintaining burden is shared (or currently delegated).

So a few minutes after Darkroom was finished, a new RAW importer from Krita was written (things are much easier when you know the API of a library):

I have some RAWorld Domination Plan for Krita, I am toying with the idea of editing the RAW file inside Krita instead of importing it, but that’s for an other time, maybe in a year or two.

Howto: fun blog entry while stabilizing software

Boudewijn just mentioned that KOffice was entering soft-freeze and that it would mean more boring blog entries while we work on stabilizing KOffice. Well I must disagree with that, I usually find the most annoying bugs while preparing blog entry, and when working on stabilizing Krita, it usually wake up my creativity part (mostly because it’s not sucked by my coder side while designing new features), which can be turn in fun entries.

I just bought the new Super Smash Brawl for WII (yeah not the best way to concentrate yourself on bug fixing, but very good to clear your mind), which includes the infamous Mr Game & Watch character (probably for nostalgic reason, my favorite). So this has inspired me: it should be easy to reproduce it using Karbon:

And I must say, the work that was done on Karbon14 by Jan Hambrecht for 2.0 is really impressive, the curve editing is really good now (compared to older version). And the nice thing is that you can use what you have create in Karbon14 directly in other KOffice and you will benefit from the same editing capabilities:

Kross/KDEBindings Meeting in Berlin : Day 3

It is now the last day of the meeting. Somehow, Aleix managed to convince Thomas and me to try KDevelop4, I must say I am impressed by the new version, I have been a KDevelop3 user for years, but mostly because it’s the less worse solution out there for C++, but now it seems that I might use KDevelop4, also because I want to use it ! The coolest new feature (apart the C++ completion-that-just-work) is the possibility to define a list of target to recompile, which is really nice since I often work on two or three libraries/plugins and I only want to recompile those three, so now I just have to make a list with those targets, and press compile, and voila !

Today, I spend again some time on the Krita Kross plugins, and now it’s possible to create canvas decoration with a script.

In the following screenshots the vanishing points are created by a ruby script:

Here is the code to achieve that:

def drawDecoration( gc, documentOffset, area, converter)
x_c = 800
y_c = 600
painter = Qt::Internal.kross2smoke( gc, Qt::Painter )
painter.setPen(, 1, Qt::SolidLine ) )
painter.drawLine(0, y_c, 1000, y_c)
painter.drawLine(0, 0, x_c, y_c)
painter.drawLine(0, 1000, x_c, y_c)
painter.drawLine(1000, 0, x_c, y_c)
painter.drawLine(1000, 1000, x_c, y_c)

It’s far from being perfect, especially the “painter = Qt::Internal.kross2smoke( gc, Qt::Painter )” line, and also the “converter” is useless, since you can’t access its function. And I won’t have the time to fix those points before Krita 2.1. But this has allowed me to test quiet a few features of Kross and QtRuby working together.

During that time, Thomas is fighting with making the PHP bindings links and loading on Linux, Arno, Richard and Sebastian are fighting with plasma to get ruby and C# plasmoids working.

On other news, today, we discussed about documentation and tutorials (as numerodix mentioned it on my blog entry of yesterday, it’s a big issue to attract new users). The solution is of course to use techbase, there is already a section called Rapid Application Development with some examples and starting point on the subject, or a section on supported languages, it now needs content and probably a little organization.

For tonight, Ellen Reitmayr offered to organize a barbecue, unfortunately, the weather is rainy on Berlin, and we had to cancel that, so instead we are going to code and most likely eat pizza like real geeks.

Kross/KDEBindings Meeting in Berlin : Day 2

12 July, 2008 1 comment

So this is the second day of the meeting. Today, we were supposed to speak of the big problem of documentation and examples for bindings, which are truly needed to attract people to use the bindings, but somehow we got absorbed by a coding frenzy, and we only talk about how to organize the kdebindings module (and decide that it would need to be discussed with packagers). So today, I mostly tried to fixed the two annoying crashes that I had with Krita + Kross + QtRuby, and somehow I am unhappy, since I only worked around them, the first one was caused by a nuisance of C++, you can’t know when static objects are going to be deleted, and one of them is deleted too early. Since it happen at exit time, the dirty solution is to not free all memory (it’s not a big deal, but it’s plain ugly). The second issue was caused by a call to the garbage collector of ruby, while an object returned by a ruby function was not anymore referenced, I just removed the call to the garbage collector (clean, isn’t it ?). Then in the afternoon, I spend a little time making sure the build system work as expected, meaning auto-detection of libraries and auto-activation of features, I hope it will make the bindings easier to build in the future.

Kross/KDEBindings Meeting in Berlin : Day 1

This week-end, I am attending the Kross/KDEBindings meeting at the KDAB office in Berlin, organized by Thomas Moenicke (working on PHP bindings), with Mauro Iazzi (working on LUA bindings), Sebastian Sauer (main author of Kross), Arno Rehn (working on Smoke and on Mono bindings), Richard Dale (working on Ruby and Mono bindings), Simon Edwards (working on PyKDE bindings), Aleix Pol (working on Kross for KDevelop), and me (as Kross tester, and Kross/Ruby author).

Sorry, no picture yet, since I forgot to take my card reader, but they will come later 🙂 This morning we discussed how to improve collaboration between Kross and Bindings, and also did some coding while discussing.

So I had an other look at how to create dockers in Ruby (or any other language with Qt bindings and a kross binding, which is basically only Ruby and Python at the moment). And I end up mostly tracking a bug in Krita, but in the end I have something mostly working:

It’s not visible in the screenshot, but the flipbook docker (which is a docker that allows to add images to a list, and then easily switch between images that you want to edit) was written in Ruby (you can see the actual code here). There are still some rough edge, in fact two crashes, one very bad involving the garbage collector, and an other not nice one at exit.

One of the most exciting things that have happen during this coding session is that at some point Sebastian asked Richard, how long it would take to add a new binding in Smoke, for instance, for QtScript. 20 minutes later, it was done and commited in subversion !

This afternoon, we talk a little bit about what exactly we are doing, and what are the difficulties/challenges we have. So Sebastian started with a presentation on Kross (on how easy it is to use it inside your application), then Richard explained us how Smoke is working for dynamic languages, and Arno told us what he did to extend Smoke for static languages. Then Simon talked a little bit about Python and SIP, then it was the turn of Mauro for the LUA bindings. Now, Aleix is going to talk about KDevelop and use of Kross in KDevelop.

Then we are going back to coding and waiting for the dinner.