epic fail!

When it comes to application development, almost every time there is the need to store data persistently between application launches. Setting up a relational database schema is one thing, but maintaining the relation between the python objects and the database tables is a serious task. Luckily for me being a opportunistic developer, there are many frameworks which aim at scratching that itch. In fact there are so many that I am having trouble chosing.

I tried one or two, but always found myself somewhat constrained, especially when it comes to schema evolution or trying to trigger gui updates from data events. So a little search over google code tells me that basically all the projects that make use of these frameworks are web applications. Canonical even developed their own for the use with launchpad et all.

So my question to the world is twofold:

1) What do existing python desktop applications use? Do they all take care of the “M” in the MVC themselves? I find that hard to believe. It appears to me as I take one step back that actually I do not a database. I need persistent objects. Exaile uses shelve, but is does not look very handy to use.

2) What shall I as an opportunistic developer use? Well… the opportunistic echo is couchDB, but even in the projects intro page it says quite clearly that it is not what I want.

It hasn’t gotten much attention in the ubuntu universe yet, but Google announced ChromeOS. The sparse information available tells you that it will be a google chrome browser running on top of a linux kernel running webapps. It will be free. As in speech.

It is targetet towards netbooks and “web oriented use”. All the apps will not be tied to the chrome browser, but will run in any other standard conformant browser.

Now we all know that google has already a decent set of web applications that mean to replace long existing tools (Office, webmail, calendar, instant messaging). The (german) online media sees this as the next big attack on microsoft, targeting windows.

This is where they lose me. For ChromeOS to replace windows (or any other currently used desktop OS), it either has to offer the same set of applications or all the users will use their PCs “web oriented” exclusivley in the future. I don’t see any of this happening.

So what is in it for “us”? Just some additional webapps that we can use or not? A fast OS that we can run on our netbooks? A new approach to computing that will make our current OS obsolete?

It is not news that Empathy will replace Pidgin in Karmic. I do not want to comment on the decision, that has all been laid out epically. I want to join in the good spirit and try to get the best out of it. There is a PPA you can use to get the latest release (I still don’t get the meshwork of Telepathy, Empathy, Gossip. Who is the specification reference implementation of whose UI taken frontend, backend protocol library multiprotocol instant messenger for gnome??)

My first impression: Slick, but how do I group the different accounts of one person?

Slightly after that: Oh, I can’t. Well, this is clearly a feature that should not be so hard to accomplish and is such an obvious disadvantage against pidgin that the devs will implement this soonish because it would be such easy karma from the users. Right? Epic NO!

There is a bug report since 2 years. Over a dozen other bugs have been marked as duplicates, so there seems to be user attention for this. Throughout the bug report several things get clear:

• Implementing “Persons” in the right way across the whole bubble persons interact in is not trivial.
• This Bug is far from beeing fixed, or even triaged
• There is no clear drive (in terms of roadmap, responsibility)
• There is no effort or aim to provide a workaround to “provide” this feature. Pidgin doesn’t have what the people project talks about either. But in pidgin I can group one person into one contact. I know that empathy is not a rewrite of pidgin. I know that empathy does not try to substitute pidgin 1:1

So I kind of wonder? What can we do?

Accept that it will probably not be available for a long time? Of course, if it bugs me, I can fix it myself. As I am neither experienced nor know anything about this project, that is not the option?

But I want to come back to the spirit. What is the best way to hug Empathy so hard it will fix this bug?

The coders among us geeks will probably agree: The fuel that gets us going is the passion the create something new and see something grow that I created myself. Fuelled by that energy, you forget time, space and basic human needs while hacking on a cool feature. One catchy thing about passion is that it cannot be forced or bought. That is why software development for a commercial product is often not as fulfilling as hacking at home, in your private space and by your rules. What is the consequence of this?

You only contribute your time to the area that you enjoy most, maximizing the scratch for your geek itch. The outcome?

You start several promosing projects, only to find yourself switching to the next one when your previous milestone has been reached or simply another topic offers something more “sexy” to work on than your current one. This behavior is perfectly okay. You don’t get paid, you do it in your free time and for fun. So if you maximize your fun, you use coding exactly in the way you wanted to, you have the most fun possible.

So by this you get to know new technology, your software design skills emerge and you replenish your energy with rewarding “it works!!” moments. Unfortunately, this does not ultimately lead to better software, because good software is far more than coded features.
You have to do documentation, bug triaging (filing first would be good), give some love to your release page/space.. Oh, no, wait! I went too fast. *Before* doing all that you need to define release critical milestones, agree on a common goal for your release and drive the development into a road where it is actually targeted towards your release milestones, i.e. not working on features that are for the next release (because they are so big they essentially break the whole functionality until they are finished). And there is our main point! You have to *drive* the development. That means, restraining it from its pure hedonistic purpose of maximizing the fun of the coder towards getting the coder to code something that is not in his focus of interest.

Now you could argue that the focus of the coder is to produce quality software that people can use, but out of my experience I have to say that this is too optimistic. You want fast and sexy results, rushes of adrenaline and “whuhuuu!” moments rather than editing 200 docstrings or writing an tutorial on how to use a special function.

So why am I whining about this? The reason is that I have hit rock-bottom with my dearest pet project. It started of quick and we could “release” 0.1 quite early. The reason for that is that it was clear that the choices where either to redesign the codebase of stop doing it. We did the former and were quickly back to what 0.1 provided with beeing able to extend it so easily and really “get going”. It was then that there was a magical moment where the enthusiasm just faded. We were near to getting 0.2 ready, but deep inside i wanted to start hacking on post 0.2 features rather than finishing up that release. On the other hand it was clear that “release early, release often” (metalink ) is not just phrase, but a necessity if you want to draw peoples attention to what we are doing. Especially if we are talking about a framework.
So i tried *really* hard to get to the point:

• I created bug reports for the 2 main showstopper bugs
• I set up a webpage for the project
• I wrote tutorials, documented the code, posted screenshots, I even released the thing although I know that there is still much work to be done.

Now I just don’t know what else to do. When you browse the intarwebs you often come along webistes of projects that are deprecated or no longer beeing developed. But they were active once. They had a (vibrant) community around them pushing the next release.

I want to learn something out of this:
What can you do to prevent this? I mean there are many examples where small groups of people or even single persons are producing great software for many release cycles.
How do you actually drive the release of an starting open source project? There is no pressure. There is no way telling people what to do.
Are the great projects that we see and use every day really just the gems that survived the strong selection of time and motivation? That would be a hard lesson for me to learn…

Normally I don’t like those memes because they don’t deliver any valuable information, but that’s not my point. This one is different because you can look at the very recently taken photos of the people and compare them to their hackergotchi on the planet. We notice a few things:

Richard Johnson apparently never smiles.
Greg Grossmeier apparently only owns one wool cap.

What else do you notice?

[Update]I just figured out I had a terrible bug in the gedit plugin which caused the wizardy to work only once. This should be fixed now in 1.0b2[Update]

[Update]I find this script useful enough, so I created a gedit plugin for it and hosted is on google code[Update]

I work on a few little projects. When I get going I focus solely on the new feature or on squashing that bug, but not on publishable code. This is a flow in my working process but just who I am. The consequence of that behavior is: I neglect proper documentation. And by proper documentation I mean epydoc conforming docstrings.

When the time comes and you want to release something, especially when you want people to look at your code and work with it, you realise that you need proper documentation. So I sat down and started to write the docstrings. Writing documentation can actually be fun! What certainly is NO fun is writing the overhead: “”" to start the docstring and end it and @param and @type for each variable. There must be a way to avoid this boring and purely repetitive task. So I searched the intarwebs and, to my surprise, found nothing. While I still refuse to believe that everybody writes their docstrings on the fly, or uses an IDE das generates the stubs, my buddy and me also refused to write all the donkey code ourselves. So we started what I want to share with you:

A python script that inserts docstring stubs into a file. We used the oppurtunity to revive our regular expression skills. (Kudos to Kodos! If you want to develop a regex on the fly, Kodos is for you…).

So here goes:

import re

# fileNames to process
baseFile = "Game.py"
outputFile = "Game_enhanced.py"

# configuration parameters
# method parameters to skip
skip = ["self"]
# number of spaces to insert for identation
ident = 4

# we have to keep track of how many chars we already inserted because
# we are modifying the string while processing it
inserted = 0

def insert(original, new, pos):
    “”"
    inserts new into original at pos
    @type original: string
    @type new: string
    @type pos: integer
    “”"
    return original[:pos] + new + original[pos:]

def newline(current_ident):
    “”"
    returns \n with current_ident + global ident spaces attached
    @type current_ident: integer
    @param current_ident: the identation of the line we are wrapping
    “”"
    global ident
    res = “”
    for i in range(0,current_ident + ident):
        res += ” ”
    return “\n” + res

# regular expressions
method_pattern = re.compile(’.*def .*.’)
variable_pattern = re.compile(’[(].*[)]‘)
variable_name_pattern = re.compile(’,')
docstring_pattern = re.compile(’\s*”"”‘)

# read in the file to be processed
f = open(baseFile, “r”)
text = f.read()

# find all methods
method_iter = method_pattern.finditer(text)

# process each method
for item in method_iter:
    # the position of the docstring
    # here we have to take into account what has already been inserted
    pos = item.end() + inserted
    # the identation of the method is the distance from the beginning of the
    # line till the “d”
    current_ident = item.group().find(”d”)
    # test if there already is a docstring: the next non-whitespace should be “”"
    if docstring_pattern.match(text[pos:]):
        # debug/info notice on the konsole
        #print item.group(), ” already has a docstring”
        pass
    else:
        variables = []
        #search vor the (…) section
        vars = variable_pattern.search(item.group())
        vars = vars.group()
        # get rid of the paranthesis
        vars = vars.replace(’(',”)
        vars = vars.replace(’)',”)
        # split the variables by commata
        for var in variable_name_pattern.split(vars):
            # get rid of spaces
            var = var.strip()
            # and use only the first word, we get rid of standard values
            var = var.partition(” “)[0]
            # test for exclusion
            if not var in skip:
                variables.append(var)
        # generate the docstring
        docstring = newline(current_ident) + ‘\”\”\”‘ + newline(current_ident)\
                    + ‘FIXME’ + newline(current_ident)
        # add the @ lines
        for var in variables:
            docstring += ‘@param ‘+var+’:’ + newline(current_ident)\
                        +’@type ‘+var+’:’ + newline(current_ident)
        # close it
        docstring += ‘\”\”\”‘

        #insert the docstring into the text
        text = insert(text, docstring, pos)
        # record how many chars have been inserted
        inserted += len(docstring)

# open the output file
fo = open(outputFile, ‘w’)
# write the output
fo.write(text)

Now the trained eye notices a couple of things:

• It is neither very clever or complicated. All it does is search for a method declaration, check if a docstring is present, parse the variable names (stripping of keywords), generate a docstring with @param and @type lines and paste it to the text.
• It completely ignores @return and @rtype stuff because when considering nested functions we quickly came to the insight that detecting returns is not trivial. The “return” of a function does neither have to be before the next “def” nor does the identation give any sufficient info. As this is the only information our script gives us, we skipped that. In order to properly detect the return stuff we would have to parse the whole method body (including any inner methods, i.e. we would have to parse everything till the ident matches the ident of the def again) and make a judgement which return belongs to which def based on all the idents in between those two. If between a def and a return there is another def, then the return belongs to the first if the ident of the return is lower than the ident of the second def.
• It uses spaces and no tabs to do idents
• It is not a usable module. Ideally, the thing would be a module which would provides a method to pass a list of files and some configuration stuff to.
• Again: It’s simple!

Comments and suggestions are very welcome. And I would love to have a “D’Oh!!” moment when somebody points me to where we could have achieved that in 5 minutes time…

In case someone has not already heard it. Jono Bacon (our ubuntu community manager) released the first album of Severed Fifth, named “Denied by reign”.

As Jono has blogged before several times, this album is not just a  normal record, but the start of a new and exciting project.

I generally am into this kind of music, and I must say I totally love the album. In terms of professionality and “sound” it is (at least to my ears) totally in sync with todays standards. What marks its style for me is the mix of “machine gun like double bass” and in contrast the clear and not so exagurated vocals. The result is a very smooth but never boring or soft sounding atmosphere.

And if you now bear in mind, that all instruments, vocals, writing, recording, mixing and producing where done by one guy, you can only say “wow”!

Rock on, Jono!

The only flaw for me: I generally don’t think that music should include statements on politics.

GIMP 2.6 was released. It is all over the planet.

I found a link to a ppa for intrepid in the forum and I (as the guys in this thread) doubt that it will hit any official repo soon.

So, still waiting for the hardy deb…

I like to play an occasional game of dota, the famous Warcraft III - The Frozen Throne mod, with my friends. It works perfectly with wine since I can remember (so, probably feisty). You don’t even have to install it using wine, just launch your windows installation and your fine. In fact, I kept my initial Warcraft III installation all the time in my ~/.wine directory and never had any problems.

Yesterday, a buddy of mine asked me to play a round. Not to note that my perfomance would be rusty at best, upon starting up the game my screen went black and told me it was “out of range”. This usually happens when the refresh rate is higher than the monitor can handle. I tried several tweaks in the registry, but no luck. I then stumbled upon this bug in launchpad against xorg that is excactly the same problem.

This is where I get confused: This bug has been openend quite some time ago and also some people have said that they are experiencing the same problem. Yet, the bug is in status “incomplete”. I commented that I have the same issue and attached my XOrg log. Now my question: Is that all I can do? What is the normal lifecycle of a bug? Is this problem just too uncommon, too little? What could I (as an unexperienced “bug triager”) do to help?

First, a little disclaimer:

I am not a good photographer. All I know is that longer shutter values give more light, so does a wider aperture. That’s it.

I do not own a good camera. It even isn’t a SLR. It is so old, is sucessor already has a sucessor.

Despite these more than obvious limitations, I managed to create some decent looking shots, all with the help of the above mentioned equipment and open source software.

In particular, I am talking about:

Hugin - the panorama stitcher. To me, hugin is one of the greatest pieces of F(L)OSS to date. It builds on extremely powerfull tools which feature heavy mathematics and insanely clever algorithms that are way over my head, yet it gives me the power to use these tools to create results that leave my viewers with dropped jars. And all of this with no more than 4 dialogs, each of which as easy as browsing the web.

Gimp - Gimp probably does not need an introduction. The Title says it all: GNU Image Manipulation Program. Nothing more, nothing less. In this tutorial I will only use a very small function of Gimp’s features:

• automatic color adjustment
• selecting and cropping a rectangular area out of a picture and setting the selection as the new canvas
• the incredible lomo plugin
  

Phatch - Photo batch processing. Although not exactly needed for panorama creation, it still makes my list of the must-have applications for image processing. It’s features include almost every common task in (mass) image processing. What makes it a killer for me is:

• it’s power. Almost nothing you do on a lot of images that can’t be automated here
• it’s style. Beautiful icons as well as ui. It matters
• it’s reusability. Create a sequence of actions once and then apply them over and over again.

The Start

It starts with the pictures. This is the most important steps. If you do well here, the rest of the steps will go like clockwork. If you do badly here, the rest will be a neverending pain and the result will not be satisfying. So what are the cornerstones of a good set of pictures for a panorama?

Not too close focus. If you focus on something that is not very far away from the point you shoot, you run into a problem of perspective when stitching the photos. The result will be that your image will be far from rectangular but some sort of rainbow shape. That is why it is extremely difficuilt to shoot a panorama from, let’s say, your room. It is not impossible, only I didn’t manage it yet.

Constant camera parameters. When shooting panoramas, you shoot most parts of the scenary more than once. But if you have the camera on an automatic adjustment mode, the parameters of aperture and shutter will adjust each time you move the camera, resulting in different shots of the same area. Although Hugin has a great enblending feature that tries to adjust the images, it cannot do miracles. If you have pictures with different gamma, you will have soft edges instead of hard ones, but you will have edges and edges kill the feeling of the panorama beeing a single picture.

Constant horizon. As stupid as it may sound: This one is important! Prior to shooting your pictures, you have to think about the horizon line of your panaroama. By horizon line I mean the middle line of your picture. It should be a straight line that is parallel to the natural horizon. If you mess this up, you will loose much quality, at best.

Here are the step-by-step instructions to shooting a panroama set of pictures:

1. Set the camera to landscape mode and let it adjust to what you think to be a median point of your scene in terms of exposure
2. remember the values the camera chose for shutter and aperture, switch to manual mode and enter these values
3. scan the whole scene and watch the exposure indication
4. reflect what your shutter and aperture values mean for the resulting images. Which parts do you want to be the best exposed? Which parts can be over/under exposed?
5. Adjust shutter and aperture. Switch back to 4. until you are satisfied
6. shoot images with an overlap of ~30%-40% without moving. Let the autofocus of the camera adjust to every image, this does not affect the resulting exposure.

In the end your pictures could look something like this:

Stitching

Now go back to your lab and launch Hugin.

Now, Hugin is very powerful. Over at their site, there are wonderful tutorials, docu and tech explanations. So I won’t even try to get into that. I will use Hugin to do the following:

1. Load the images
2. Set a position and light anchor
3. Set control points (i.e. points in the pictures that occur in more than one image). This can be done via an assistant, more about this soon.
4. Optimize the images according to these control points
5. Preview the output
6. set the parameters of the resulting panorama
7. Stitch and blend the beast

A Note about the hugin version:

The current version in the hardy repos is 0.7b4. This version works fine for me. I encounter one bug from time to time: When you resize the image preview panels in the control point area, sometimes the images vanish, leaving you with a gray widget. Don’t panic, just save your project, exit hugin and start it again.

At the time of writing, hugin version 0.7rc2 has been released. It has much more features than 0.7b4. It can do “exposure fusion” and “HDR”. I do not exactly understand what this is, and the changelog isn’t of much help to me. In fact, I never used them. Who wants to be at the bleeding edge or use those new features, there is an excellent compilation howto at the pantotools wiki. I followed the steps there and everything worked out of the box. But be prepared to install a decent pile of packages, check out several projects vom versioning systems and compile for … quite some time.

The Assistant

Hugin offers an assistant that guides you through the creation process like windows installers do. I prefer to do the manual round as I have more control about what happens and what happens when. So the Starting point for me is the files dialog:

Here we add the files involved in our panorama. Make sure the files are in the correct ordering or add them in the correct order. Then select the middle image and make it an anchor for both position and light.

Autopano

Now you are at a turning point. You can autopano make search for control points, or set them manually.

The advantages of autopano:

• It compares every pair of input images, not just adjacent pairs. You will get alot of control points if you shot with enough overlay.
• It finds control points where the human eye would not. Imagine you shot a forest or something like that, you are out of luck. Hugin is not. I think each image gets transformed into a (huge) set of defining points and these “graphs” are than scanned for simuliarities. This method does not fail.

The disadvantages of autopano:

• It’s slow. This is not exaclty true. Compared to what it does, it is super fast. But what it does is really time consuming. Also, it’s time growth is O(n²) if n is the amount of pictures, as it searches every pair (I am just assuming it is like that, I do not know for sure and would be delighted to get a comment if I am wrong).
• Its choice of points lacks human intuition. Now how can that be a disadvantage? When you set points manually, you put some brain in your choice. You choose the points carefully in order to make them good points, autopano cannot do that. It just searches for points (using whatever algorithm) until it has found as many as you told it to find and moves on.

Control Points

So what makes a control point a good control point?

• Focus. Try to chose points that are in your focus area. I you shoot a house 20m away from you, don’t pick a TV-tower 5km into the city. If you shoot a mountain line, don’t pick a car on the parking lot you are standing on
• Perspective. Try to chose points that are significant indicators of perspective. Edges of buildings are good. Corners of windows are good. But be aware that a point is not a point in the mathematical sense of the word (i.e. a circle with radius 0), but rather a smal area. So if you chose an edge of a house, but behind that house is another house which is 50m behind the one you chose, make sure that your point does not include the second house. If it does, you confuse the software, because if you move your camera (or even worse, yourself) the 2 points will shift differently.
• Sufficiency. Try to chose points that cover your whole scenary. Try to chose points from the corners of the individual images and use the same point again in the next pair.

My experience is that it is not necessarily better to define many points. While control points are absolutely vital to the functionality of hugin, each control point constrains the stitching and blending tools in their ability to produce the best results. Chose 3-5 control points that match the criteria above. Do not chose control points near “critcal” areas, such as people or moving cars. These areas will look best in the outcome if the tools did not have to maintain on e of these points, but could produce the best picture.

Optimization

When you are done with your control points. It is time to lay your fate in the hands of hugin. Again, I habe no clue what is really going on under the hood, but I think the optimization step works like this:

With the defined control points, the images are “pinned” together at these points. Of course, this will not work exactly. The world is 3D, a photo 2D. So what hugin does is paint the image on the skin of an imaginary ball and adjust the parameters until the points are as close as possible. The outcome of this process is shown to you when you press “optimzie now” in the optimization panel:

These values show the distances between the control points after the optimization. You get an average, a maximum and a variance. To understand these values you have to have some basic statistic knowledge. If your average is low, but you have a high max (e.g. average = 1, max = 10) then you most probably chose one bad point. If you have a high variance, you screwed up. Generally speaking, everything under 1 is superb ( 1 think this are pixels, so everything under 1 is .. hardly existant), single points with an error < 10 can be corrected, but everything wors will not work.

After the optimization, you will see the optimized values for yaw, pitch and roll in the optimization pane. Also, If you go back to the control points, you now see the error of each point displayed. In that way, you can rework bad ones, keep good ones and optimize again.

When you are done, have a look at the preview:

Now this already looks really good. You can do alot of thing here, like adjusting viewpoints and whatsoever. I never used them so far.

Actual Stitch

Now, finally on to the Stitching pane:

Here you leave the projection as equirectangular, your stitcher is nona, enblend does your blending and you want to produce one tiff file with soft enblending enabled. Actually, I don’t know if you want to do that, but that’s what I use for this tutorial and in normal use. Push the compute angle/size buttons once and … stitch them together. The result will be one big tiff file, containing our panorama as well as some transparent space.

Gimp

Let’s open it in Gimp for processing:

Use the rectangular mask tool to mark the area of the image you want to keep. Then select Image -> reduce to selection (I am just guessing the englisch names here). You could also ctrl-x and insert as new image, but that would mean gimp has to move your selection to the clipboard and then create a new file with about the same size as our tiff. If the panorama is large, this uses alot of time and space if it not locks up your PC (depending on RAM, of course). So the cropped image should look something like this:

The next step is magic to me. My camera is not very good at capturing to real colors, a SLR camera does this much better and the images get not imporved very much by this step, but with my images this is a massive improvement. Open colors -> values. This brings up a dialog where you can adjust the range of the values for colors. It has an “automatic” button which pricudes very good results on images shot with my camera. If your camera is already good, you won’t see so much improvement here. In this dialog you can also generally lighten or darken your image. Beneath the historgram are 2 triangles. They represent the dark and light end of the scheme. If you move one of them all colors will be lighten up (or darkened).

Now it is time to save the image, because the stuf I do afterwards is of questionable taste and sometimes makes the images look fake. Usually I overwrite the tiff image produced by hugin because I see no point in maintaining the huge and bulky image.

Next is the lomo filter. In the comments of the page it describes lomo:

“Technically, this plugin creates a vignetting effect, it darkens the edges and brightens the center, while increasing the contrast of the image.”

One has to understand this in order to predict the effect of this filter. The center will be lighter, the edges will be darker. The contrast will be higher. What this means is that eg the clouds in the sky will vanish, if the focus of your image is not in the center (like when doing a groupfoto), the people on the border will become darker. You have 2 ways to influence how the plugin works. You can select the area it shall be applied to and you can adjust the 3 parameters of the plugin. You can find the filter at “Filter -> Light and shadow -> lomo”, once you copied the scm file to ~/.gimp-2.4/scripts/ and restarted gimp.

To apply the filter just to one area, simply use the various selection tools to select the area of your choice and run the filter. You have to bear in mind that the current selection will act as the total image for lomo. So if you select only your center area, lomo will treat this as a full canvas and make the border of it darker and the center lighter. As for the filter options:

Vignetting softness indicates how soft the vignette will be. If you wish a higher concentration in the centre, chose a higher value. A lower value will treat the whole area more equally.

Saturation is the general strength of the filter. Adjust to fit your level.

Contrast is the level of differences the filter will create.

As a rule of thumb: If you want a softer effect increase the softness and lower both the saturation and contrast (I always have the same values for saturation and contrast as changing only one does not have much impact). This is our sample images after lomo:

To describe the effect with my own words: it looks like a grey fog has been pulled off the image. On the downside, the sky looks now almost entirely white, creating a non-realistic scenary. So let’s do it again without the sky. To do so, select the sky with the wand and invert the selection and repeat the filter.

Now the sky looks the same as before and the foreground has been “enhanced”.

Phatch

There is not much value in editing one single photo with a batch processor and the focus of this tutorial really is the panorama stuff, so I will not get dirty with phatch right here. There is a great tutorial in their wiki to get started.

Closing notes

As you may have noticed during reading, I am not an expert in any of the domains covered here. I just wanted to share my personal experience and learning curve with anyone interested. That beeing said, it directly follows that I have made many mistakes througout the tutorial. If you spot one, please leave a comment. Thank you.

The process described above is just one (pretty standard) way to process your pictures. There are countless variations. Hugin alone offers dozen. You can play with viewpoints or the new blending methods if you dare to compile 0.7rc2 (which you should). Just one example that has happened quite a few times to me.

The Problem: You have a person, car or other moving object on your series of shots which is in different states in different pictures. You can try to leave as much power to hugin by not setting control points near the area, and very often hugin succeeds in sorting out which one to take and which one to overwrite. But sometimes you will not be satisfied. Or the same usecase: You have something/someone in one photo but not in the other and hugin keeps deleting it.

The solution: Order hugin to make not one tiff, but a multilayered tiff. This will result in an even larger file, but if you open it with gimp every of your input images will be fully intact (with the transformations done by hugin) and stored in one dedicated layer. What you can do now is erase an area in one layer to let the one below shine through. Feel free to exploit all the power of gimps tools.