Step One: Make photos

Very easy: stay somewhere, like on a top of a mountain, and make photos all around you. Photos must overlap, about 25-30% is sufficient. Last photo must overlap the first one. Photos must be well aligned, otherwise your panorama will be wavy. Use manual mode if your camera has one, so you will have the same exposure and white balance for all photos.

Step Two: Stitch photos with Hugin

In the past one had to manually define common points in pictures. This was boring and time consuming. Latest versions of Hugin includes a tool called Autopano-SIFT that do this dirty work automatically. After you have installed Hugin, go to "Preferences > Autopano" menu and make sure that the "Use alternative autopano" checkbox is unchecked.

Then, in the "Assistant" tab (the one that is opened by default) click on "Load Images...", select all your photos and click "Open". The automatic panorama creation process starts. First, the autopano tool searches for matching points in your pictures; then Hugin try to find the best way to stitch them together. All this takes few minutes, or more. When the process is finished you are presented with a preview of the result. At this point it may be interesting to save the project file.

If you are happy with the preview, click on the "Stitcher" tab and set some  parameters. Actually, only one parameter is really important: "Panorama Canvas Size". It's the size of the resulting image. Choose your width, the height is updated automatically. For my example I choose the width of 5000. Then, click on "Stitch now!" button, choose a file name and wait again. After few minutes your panoramic picture is ready.

Step Three: Make QTVR with MakeCubic

This last step is not so automatic, you may have to do many tries before you reach the correct result. Launch MakeCubic program, then press Apple-O to open its working window. First, choose your panoramic file. Then, choose the width and height in pixels of the movie. Click the OK button and wait that your .mov file is ready. Open it. The result is not perfect: there is a lot of black space below and above the panorama. So, go back to MakeCubic, press Apple-O, and modify the "Tilt" parameter. Min tilt value controls the lower part of the picture and the max tilt controls the upper part. Default is -90 and 90. Set something like -30 and 30, then build a new QTVR with those parameters. The black space is now gone, probably a part of your panorama is gone too. You may have to make many tries before you reach an acceptable result.

Other parameters are also interesting. The "Pan" controls the initial horizontal rotation of the panorama, so you can choose the most nice part of the picture to present first. The "FOV" controls the zoom, I used the maximal value (= the minimal zoom). As I had the requirement to fit my .mov in 2MB I had to modify the compression. Finally, I found that setting the "Tilling" parameter to 1x1 produces smaller files without visible quality loss.

That's it.

Hugin es una poderosa herramienta multiplataforma para crear panoramas rectilíneos, cilíndricos, estereográficos, entre otros. Tiene la capacidad de unir decenas de imágenes en una sola y con el uso de Enblend borrar las lìneas de unión, corregir diferencias de luz, imágenes sobrepuestas, etcétera.

En este ejemplo, dos imágenes unidas con Hugin antes del render con Enblend

Con Hugin/Enblend, tendremos

El uso de Hugin es muy sencillo e intuitivo. Es Open Source y esta liberado bajo una licencia GPL, pueden usarlo tanto para uso personal como para fines comerciales, y como ya mencione es multiplataforma.

Aquí mi panorama de la Plaza de las Tres Culturas en Tlatelolco, Ciudad de México.

(::click para agrandar::)

Aún tiene varios pequeños errores que corregire después.

Para obtener buenos resultados es importante tomar desde el principio fotografías que tengan varios puntos en común, así Hugin tendrá mayor posibilidad de lograr una buena imágen. Estos puntos de control deben preferiblemente colocarse en objetos estáticos como construcciones, señalizaciones, piedras, etcétera, evitando a personas o árboles; excepto cuando sea necesario como por ejemplo una panoramica de una multitud en un concierto. En este caso uno debe ser rápido para fotografiar.

Hugin genera puntos de control automáticamente, pero si los resultados no les satisfacen, pueden agregarlos manualmente.

En éste caso los puntos de control que Hugin generaba no eran suficientes, surgian errores de desfasamiento en las barras del barandal y no se conectaban unas con otras correctamente. Por lo que manualmente tuve que agregar mas puntos de control.

¡Muchos más! Pero el resultado fue el correcto.

Existen varios tutoriales en la red sobre Hugin, incluso en su propia página; también un grupo en Flickr.
Por último, chequen este gran ejemplo de una panoramica de Londres generada con Hugin.

Vår nya micro!

In the short time frame of the Google Summer of Code he wrote a feature matcher and studied the performance of different potential matching algorithms.

It is unfair to him that the project is not only a difficult one, but also not one that is visible in the front end - it is a behind the scene improvement.

Onur did a good job and we now have a feature matcher to pair with Zoran Mesec's last year feature detector. The two pieces of code will still need integration and optimization work before we can claim that Hugin has achieved its objective to be free of the SIFT patent that currently taints hugin's CP generators in some jurisdictions, notably in the United States of America.

It is because of this patent that Hugin ships in most Linux distributions without CP detectors. Also Nodal Ninja customers receive a copy of Hugin without CP detector. While it is unfortunate that Hugin ships w/o CP detectors to so many users, there is a workaround for the time being. Onur and the developers are committed to continue to improve CP detection.

In panorama stitching, overlapping images are stichted together to a single image. Because they are taken at (usually) slightly different points in time, there may be movement between them. The traditional way to deal with movement is to have enough overlap covering the area and then masking out manually and painfully, in the Gimp or in Photoshop, the areas concerned.

Fahim Mannan, mentored by Daniel M. German, has written an advanced masking tool. This is quite a feat for only three months.

Masks can be useful in many stages of the process: at the stage of control points (CP) detection they are useful to tell good areas apart from bad areas. CPs further away suffer of less parallax than CPs at close distance, and at the blending stage they can help decide which of the overlapping images should be retained in the final panorama.

Like many new functionalities, this questions the current workflow model and the related GUI in Hugin, which has already been stretched from its initial design for the inclusion of photometric adjustment and the processing of image stacks. It is likely that more work is needed before this feature will hit your desktop.

Maybe not for the next release, but it is in the pipeline.

We all build (or rent or buy) a dwelling at some points in life. And we all have different standards for our dwelling depending on its purpose. We choose with greater care the family home for the next few years than the camping spot for the next week. And we are more tolerant of little annoyances such as a water leak in a camping tent that will be disbanded in a day or two, than in a house that is intended to stay solid for decades.

Similar rules apply to software. Building a Windows binary of Hugin is a matter of less than an hour once the toolchain is set up. And if that was it, I could simply put it online and satisfy these calls. But what if it starts to leak? Guess who will take the heat and comments of disappointed users?

Ideally, there is a whole quality assurance process between a build and a distributed package. Commercial companies spend hundreds of thousands of dollars on quality assurance for small incremental releases and still mess them up sometimes.

So if I want to release a new installer, after building, I take some time to do quality assurance as described here. It's not perfect, but it is what is reasonable for such a volunteer effort, and it is time that comes at a cost to my other free time activities. It's a trade-off.

Facing the trade-off between packaging for distribution a release candidate that will change, or building the Google Summer of Code projects of the students that we so carefully selected and that we are grooming to become the next generation of Hugin contributors, what would you do?

I made my choice. I am committed to our students and I owe it to them. If you want something specific from me, contact me and we can discuss your requirements. Often this boils down to an hourly rate and a deadline that fits with my prior commitments.

PTBatcher is the result of three months work of Google Summer of Code 2008 student Marko Kuder and his mentor Zoran Mesec, himself a student last year. Behind the simple interface there are a lot of details and Marko got them pretty well right.

With PTBatcher I can set up all of my stitching projects and go home while the computer works on them overnight. Or run it on a second machine dedicated to stitching on a network, possibly accessed remotely to keep the noise and heat of high-power machines away from my desk.

What I liked particularly about this project is the progression of Zoran from student to mentor. Also the fact that the two of them are at the same university and have real life contact. In these days of ever growing bandwidth and groupware there is still an element that no technology will replace in the near future: real human contact. Once a relationship is established, technology is a great enabler, but there is still nothing as good as a handshake and sharing a meal or a drink. Maybe this is the beginning of a tradition, and in 2009 we will see another student in this lineage?

Coming soon to Hugin.

It is the result of Tim Nugent's three months Google Summer of Code project, and I can't say that I had a lot of work mentoring him. Maybe because of this it does not yet have a CMake build system like all other parts of Hugin, and I only managed to build it in Linux. It wasn't even that slow on my new low-power Atom box, but who cares about speed on a secondary box sitting next to my workstation and normally used as a test box and music player?

Since I keep my stitching projects on a network drive, the process was quite easy:

• set up the project on my workstation and save it
• access it with Celeste from the Atom box
• issue the single command that runs Celeste

  $ celeste -i jpeg.pto

• open the new project file with PTBatcher (see tomorrow's sneak preview) and stitch it.

The two screenshots above are of a representative image-pair in the project. Out of a total of 20 CP, Celeste has left ten of them. Three happens to be bad and should have been removed. No false positives and a great, though not representative (too small sample) statistics.

Coming to Hugin after the 0.7.0 release.

It is the result of James Legg three months Google Summer of Code 2008 project, mentored by Pablo d'Angelo.

I've documented the changes necessary to the Hugin SDK to build with fast preview.

It requires a GPU works very well with the low end GPUs that have been integrated in chipsets for a few years now, including Intel's GMA950 that is on my new Atom motherboard (not that I will use such a low powered CPU as a stitching engine).

My apology for the bad quality screencast. Edit: the quality of my first screencast has been improved with the help of other Google Summer of Code mentors from organizations that are professionals of encoding and playing video. I also moved from Google Video to Video which at this time is much better.

Hugin uses some libraries. Using libraries is a sensible way to avoid reinventing the wheel. Sometimes libraries upgrade, like most maintained software packages. The major library used by Hugin is wxWidgets, a cross-platform GUI and tools library available on many platforms. It is wxWidgets that makes Hugin available on so many platforms, including Windows, OS X and Linux.

Hugin is quite demanding of its GUI and sometimes pushes the limits of wxWidgets. So we get to find and report bugs and collaborate with the wxWidgets team to isolate them. Then they fix them and it makes both software better.

A few months ago a newer version of wxWidgets has been released. It is an incremental improvement on the previous one with many bug fixes. The Hugin Software Development Kit (SDK) needed an update. I replaced wxWidgets 2.8.7 with 2.8.8 and it seems to work. I've used it to build the latest Hugin trunk, as well as to build the Google Summer of Code projects branches.

With popularity comes mass, and we need critical mass. It is in the mass that we'll find the next generation of tester, builders, coder. That's what Open Source is about.

Many new users have become active and when they find the inevitable bugs, they give feedback. Good. Most of them post the bug reports to the bug tracker. Very good. Often these bugs are specific to the use case and can not be identified without user help.

But we need user's help beyond simply stating "hey, there's a bug!". We need some basic information pertaining the environment in which hugin is used, and also which version of hugin and helper applications. Everything evolves so fast. And sometimes we need specific information, such as the camera make and model, the pre-process through which the images have gone, the project files, etc. Without this information, the developers can't really do much about the bug report, because the often don't have enough indication where to look at. And when they need more information, they need to contact the bug reporter.

Unfortunately some bug reporters omit the critically important step to register with Sourceforge and post their bug reports anonymously. 26 such bug reports in Hugin's bug tracker are anonymous. How can the developers contact them to get more information about the bug?

Please, do the things right - register with Sourceforge - it is free and in ten years I have not had a single instance of spam. Or at least, write in the bug report how we can contact you. Thanks.

Fahim is naturally reserved, but get him started talking about Computer Vision and you'll see the sparks of passion in his eyes. You'll hear a motivated and knowledgeable student who knows where he is going.

The Google Summer of Code is his first serious experience at contributing to Open Source, and it is turning out to be a good experience. Fahim summer project adds masking capabilities to Hugin's GUI. He is quite independent and self-motivated, and can count on expert mentorship from Daniel M. German, a former libpano maintainer and regular community contributor. Fahim posts his progress reports on his project's blog.

Even with student's life and his own GSoC project, Fahim occasionally finds the time to chime in and help out in the community when his expert skills are needed.

Recently, a change introduced in the enblend-enfuse code disrupted the building process in Windows. Fahim was quick to provide a working solution.

The above panorama of our meeting is enfused and has a little bit of ghosting. Unfortunately the deghosting code that was written for hugin during last year's Summer of Code is only applied to HDR stacks. When will it be ported as an option to enfuse? And when will we see code to extract multiple exposures from an HDR file and enfuse them together?

First, we need to enable Rotational Search. In the Preferences make sure that Rotational search is enabled in the Control Points Editor tab.

After loading the images into a project, we need to check if hugin knows that those are fisheye images. In the Camera and Lens tab, look at the Lens type (f) column. If the lens type is wrong, select any of the lines and change its type to either Circular fisheye or Full frame fisheye in the Lens section of the Geometric tab. Which of the two is easy: circular if the edges of the sensor frame are outside of the edges of the lens, and full frame if not.

For full frame fisheye, this is it - continue with the basic tutorial. For circular fisheye there is one additional step in the Crop tab.

Select all the images that will have the same crop (i.e. same orientation) and drag the mouse inside the image to match the circle approximately around the edge of the lens. You can leave the Always center Crop on d,e box checked. In the above screenshot it is unchecked because I use it to correct for small shifts of the no-parallax-point position in relation to the pano head nodal point, but that's for another tutorial.

This is a beginner's tutorial for how to manually set control points in hugin, but it is also useful for the pros dealing with a difficult stitch that require careful manual placement of CPs.

Initially, hugin Nodal Ninja Special Edition starts with the assistant.

Click on the 1. Load Images... button, select some images and open them.

If you try to click on the 2. Align... button, you will see a notification and the process will end.

If after dismissing the notification you are not on the control points tab, please select it. Make sure the checkboxes auto fine-tune and auto estimate are set.

The process in a nutshell:

• click on the approximate position of the CP on the left image.
• click on the approximate position of the CP on the right image.
• right-click to add the point to the list.
• repeat until you have enough CPs.

In detail:

When you click on the left CP, hugin will zoom in on it. Once zoomed, you may displace the CP to a precise position intended, but this is not necessary.

When you click on the right CP, just make sure that the box surrounding the mouse pointer also surrounds the area where the CP should be located. Hugin automatically fine-tunes inside that box, so that even if the left CP was not in the precise position intended, both CPs match the same position.

Fine tuning also kicks in after moving one of the points. And if for any reason fine tuning does not find the corresponding point, it will give a warning.

When the control point is where you want it, right-click and it will be added to the list of control points. Repeat until you have enough control points. Then select the next image pair and repeat for all adjacent image pairs. Simple, isn't it?

hugin Nodal Ninja Special Edition closely mirrors the current installer. The main difference is that it has no automatic control point (CP) detection because all CP detectors currently available for hugin are tainted by patents in some jurisdictions, particularly in the United States where the CD is produced and shipped.

Hugin without Autopano-SIFT-C is perfectly useable. I'll publish a tutorial soon.

With hugin Nodal Ninja customers will get more value from their pano heads.

The developers intimately familiar with the bug tracker, specifically Pablo and Gerry, thought of a simple solution: make only the pertinent processes available and gray out the rest. But how should hugin know?

When the project is ready to stitch, a single exposure panorama will have only partial overlap. A multiple exposure panorama will have 100% overlapping stacks. But what with handheld stacks? and with single exposure panoramas using auto-exposure and relying on hugin's photometric adjustments? and with the user that simply loads the pictures and heads straight to the stitcher tab?  don't ask me why, ask him. When pictures are freshly loaded their default position on the stitching surface is (0,0), making it look like a big exposures stack - even if it is a single exposure panorama waiting to be distributed on the surface by the control point generator and the optimizer.

Long story short: the subject requires more analysis. And the key learning is not to introduce user-affecting change so late in the release process.

In the heat of the discussion, Guido Kohlmeyer made the most sensible suggestion: leave this change out from the release. The next release cycle should anyway focus on the user interface. The debate is still on, but it is very likely that another release candidate will follow. Dear users, thank you for your patience.

If you haven't seen the image yet, click on the thumbnail and take a look. Accompanying the image there's also a more informative explanation of the story behind the art.

Keep your eyes peeled on my Buy Prints page, posters and framed art prints of 'Thought and Memory' will be on sale soon!

Enjoy.

Terry has an interest in photometrology, and he unearthed a real jewel from oblivion and set up a SourceForge project for it.

Stereo was initially released under the GPL in October 1997 as part of Paul Sheer's M.Sc. dissertation to the Faculty of Engineering, University of the Witwatersrand, Johannesburg, South Africa. It has survived without maintainer ever since on the Italian mirror of the GRASS-GIS project, that like hugin participates in the current Google Summer of Code. There is even an old tutorial for it.

Like panorama stitching in hugin, photometrology in stereo requires control points (CP) between images. For panorama stitching the no-parallax-point (NPP) should be held in a constant position for all images. For stereo photometrology the NPP position should be controlled so that there is a known distance between each pair of images to allow for the triangulation from 2D to 3D.

Back in 1997, setting a CP was a cumbersome manual task of reading (x,y) pixel coordinates on each of the two adjacent images and adding them manually to a list. Repeat. The advent of automatic CP generation has massively simplified the task and extended the reach of stitching software to new applications such as gigapixel panoramas.

The potential is here for automatic CP generation to do the same for stereo photogrammetry and Terry needs help. Any smart and gifted coder out there that can help Terry revive stereo and bring it where no man has gone before?

If you know Paul Sheer, let him know that his child is still alive and in need of love and development.

The release paves the way for inclusion in upcoming updated Linux distributions. Binaries for other systems will be made available soon.

Despite the beta5 release, bug fixing goes on at an increased pace. Gerry Patterson has not stopped working through the bug tracker and has already corrected half a dozen bugs beyond beta5.

Recently he was co-author of a scientific paper and he used Hugin to explain the machinery that produces the ultra-high-resolution images.

During the Google Summer of Code 2008 application process I was wondering why he did not apply. I understood later on what his project for the summer was when this charming couple visited us during a one month camping trek through Canada.

Stay tuned!

Time flies and it is already time for the mid term evaluation of our Google Summer of Code students. All projects are on track and we might achieve our first zero attrition year. The main reason for that is that we improved significantly our selection process with a simple skill test: applicants were required to provide a patch to the code. The goal was to show basic command of the build chain so that they can get down to the code from day one. This was possible thanks to a documentation effort that made the build process almost dummy-proof.

Another improvement this year is the interaction with the community. Students have been directed from the start to the mailing list where they introduced themselves and their projects. They got plenty of positive feedback, feature requests and test reports.

The one extra thing I have organized, both last year and this year, was a donation of pano gear. This year it is a Nodal Ninja 3 MkII, and because Bill Bailey is so generous, it comes with plenty of extra goodies. While I do not think that our students or mentors need extra motivation, I believe this will help produce better code because understanding the gear means understanding the user for whom the code is being written.

Happy coding!