Monthly Archive for August, 2008

Photo KDE Tutorial 1-3: White balance

This is the 3rd tutorial in this series, trying to show how effective KDE photography applications can be for fixing and/or improving your photographs overall. In the first and second tutorials we addressed light exposure issues. Ie, we addressed photos that had regions gone too dark or too bright, and we showed how to fix them using either the levels tool or the curves tool.

In this third part we will continue addressing the light issues, but we will target color issues rather than brightness issues.

So lets begin!

Most of the times we use our cameras outdoors. Light is nice, sun shines, and we get nice pictures out of our cameras. But sometimes we need to take pictures indoors, in parties or conferences, and light conditions aren’t the best. We even take pictures with flash, sometimes. So what’s the problem? - you will ask. Well, many times when taking photos the effect goes unnoticed, but indoor lights are either tungsten lights (yellowish or orangeish) or fluorescent lights (more bluish), and depending on the light conditions, the photo results vary a lot.

Lets see the following example, from Akademy 2008 pictures, kindly donated by Sebastian Kügler for this tutorial:

Yes, it’s Mike and Paul, while discussing backwards compatibility issues of core kdelibs changes, in a serious akademy meeting Sticking out tongue Uh, isn’t Mike’s face a bit reddish? does he actually look like this? is it due to the heated discussion they are having? … oh wait… no, that’s just poor lighting Eye-wink

So what happenned to that photo. Simply, the room was poorly illuminated by yellowish tungsten lamps, and the camera captured that nicely. Our eyes (or rather, our brain), compensate it automatically to identify the colors, but cameras not always manage doing that.

Most or all digital cameras these days allow correcting that when taking the picture, with an option called “white balance (WB) setting”. The menu is usually similar to the following image:

If the camera was set like in this picture (light bulb/tungsten light selected), the picture would have turned out better colored. In the same camera menu, you will find many more options for cloudy/sunny days, fluorescent light, flash light, etc. Please refer to your own camera’s manual for more details, since each particular camera is different.

By default, though, cameras are usually preset to AWB (auto white balance). This means that the camera will try guessing which setting of all is the most adequate in each case. It can work nicely, but honestly, most of the times they fail while indoors, like in this case.

So what to do now? Showfoto to the rescue again!!!!!!

Lets open the photo in Showfoto, and select the option Color->White balance… in the menu:

You will get the following dialog popping up:

It sounds complex, right? Well, it’s very simple. The most important parts are the top two ones, marked in the image.

Both tools do exactly the same, but the input is a bit different in each case.

The second tool is what you already know. It’s equivalent to the camera’s White Balance Settings. There’s different presets for each light types: 40watt lamps, 100 watt lamps… You can select one of them, and it should fix the colors, but… which of them is the correct one for our light source? hard choice huh?

The first tool is much more flexible. It allows adjusting the Kelvin Temperature of the light. The Kelvin temperature indicates just if the light source was warmer (reddish), or colder (bluish). The more you move the slider to the right, the orange/redder the image will become. The more you move it to the left, the more blueish it will turn. But this tool can be a bit hard to tweak, and usually requires extra hard work like adjusting the green color slider. Not very easy to do.

So what’s the solution? It’s easy. In the same dialog, right besides the Kelvin temperature setting, you will find a color picker as shown in the next picture. The color picker allows us selecting a point in the original image that should have been white or gray (i.e., not colored, same R=G=B values).

Most pictures have such places. For example, Mike’s t-shirt is possibly white around his neck, given the photograph. So I clicked on it:

Impressive, isn’t it? Yes, that’s the power of white balance correction. Now you really get to see the real colors in the photograph. You can now know that his face isn’t orange (Eye-wink), the wall was actually painted yellow, and his t-shirt was dark blue. You can adjust further the tool manually by adjusting the kelvin temperature, brightness of the picture etc (for length reasons, I will leave the exploring of those tools to the reader)

I could just be satisfied with this photo and be done with the tutorial, but I am not. Look at Mike’s forehead, the tool has overexposed it and it’s all white now. There’s no information there, we clipped the histogram. Somehow, for reasons unknown to me, Showfoto’s raw tool has a tendency to do this in some photos where highlights exist and have little detail. And no matter how much you tweak the tool you may not get it right, like in this case. But I won’t give up.

If you remember from the second tutorial, we learned how to adjust the brightness of the image using curves. Lets do it then. BEFORE applying the white balance tool, lets darken a bit Mike’s forehead:

(Notice that moving the right point of the curves tool down is equivalent to using the levels tool, and moving the maximum output level left. Give it a thought Eye-wink )

And now yes, after repeating the same process, I got the forehead not that much overexposed:

In the same tool, I adjusted saturation a bit lower since the shadows were still a bit reddish, and yes. Now just press okay.
Before presenting the image, adjust a bit levels (as shown before in the first tutorial) and we are now done:

Another nice photo and tool for our collection Smiling

Thanks Mike and Paul for this great image and I really hope you enjoy these series. Feel free to give suggestions for improvements and cya in the next tutorial!

Amazing “Distributed” Summer of Code in KDevelop

Hi! My name is Evgeniy Ivanov and I was a GSoC student mentored by Alexander Dymo.
I’ve developed DVCS support in KDevelop.
It’s a small preview of working things I’ve implemented this summer (some things need some love and I will give it).

This summer was amazing: our team includes very interesting, intelligent and kind people. I wasn’t able to know all of them during one summer, but Alexander, Andreas, Amilcar, David, Vladimir, Manuel, all other guys impressed me very much. When I knew most of them have PhD I decided I want it too (but I have to study 3-3.5 years before getting Master degree :D).

Before I start, the sweetest thing (currently only for Git and with few minor glitches):

KDevelop has basic support for three most popular DVCSes now:

Mercurial and Bazaar are less supported, but I need just few lines to make them more functional, so things below are based on generic code + special Git executors(proxy) which a few lines.

Branching and VCScommitDialog used powered by Git:

Finally, whetting your appetite. Here is a screen of QGit integrated into KDevelop4. I hope in KDevelop4 we will have something like this (we have almost many things done) for all our DVCSes (Git, Mercurial, Bazaar) and Subversion.

I want to thank all people helped me during this summer:
Alexander Dymo(adymo, KDevelop) — My mentor who is strong both in GUI and Git.
Andreas Pakulat(apaku, KDevelop) — The man who can help with any part of KDevelop(or maybe even ith whole KDE && Qt).
Shawn O. Pearce (spearce, Git) — A man who is not in KDE, but who contacted my mentor and me to suggest his help.
Marco Costalba — QGit author, explained a lot of code from QGit.
Paul Mackerras — Gitk author, explained some basic algorithm (building rev history).
All guys from different IRC channels, mailinglist.
And of course Google for the amazing Open Source Program: Google summer of Code!