LWN.net Logo

Leading items

The Grumpy Editor's hugin experience

By Jonathan Corbet
September 8, 2009
Part of the LWN Grumpy Editor series
The free software community has produced a wealth of tools for the manipulation of image data. For simple changes, such as cropping, resizing, or basic contrast tweaking, any of a number of programs can be used. More complex changes will require falling back to tools like the GIMP, krita, or cinepaint. Anybody who has tried to join together two or more independent images in those tools will have discovered, however, that certain manipulations fall into a class of their own. For that kind of work, hugin would appear to be the only choice. Your editor has long intended to play with hugin; the threat of having some real work to do finally provided the necessary motivation.

The problem with just gluing two images together is simple to understand: lenses distort. Even the best lens will transform light differently toward the edges of the image than it does in the middle. Multiple images also suffer from parallax problems, even if the camera is mounted on a tripod. The result is that two overlapping images will not normally join together in a straightforward way - the pieces simply do not fit. Resolving this problem requires distorting the images in fairly tricky ways. The key to the value of a tool like hugin is not in putting images together; it is, instead, in the process of stretching and remapping those images (along with some other details like exposure matching) so that they can be put together. As an added bonus, the ability to correct lens distortion makes some other interesting applications possible.

The classic use of a tool like hugin, though, is the creation of panoramic images which cover a field larger than the camera can capture. A photographer wanting to create the best panorama should do a number of things to ensure that a set of images can be combined easily: the camera should be mounted on a tripod, and all settings should be manually selected and should be the same for every component image. A camera set for automatic exposure, for example, will vary that exposure as the camera is rotated to take the pictures; that will create differences from one image to the next. Changes in focus or depth of field will also complicate the task of properly stitching the images together.

That said, hugin does an impressive job of joining images which were not taken in optimal conditions. Feed it a set of handheld cellphone photos and you'll get something reasonable out.

To test hugin, your editor took a series of pictures of the continental divide from the eastern Colorado plains. They are not great pictures - it was not a particularly clear day - but they are sufficient to show what hugin can do. The individual images are:

[Source image] [Source image] [Source image] [Source image]

These images present some challenges; among other things, the tripod was not entirely level, so the horizon appears to tilt from one to the next. Putting them together is clearly going to require some complex manipulations. The nice thing is that hugin manages to hide that complexity from the user - most of the time. For beginning users, there is an "assistant" mode which will step through the process relatively easily. There's also a nice set of tutorials which should really be required reading for any new user.

The first step is to bring the images into hugin; that is done with the usual GTK file-chooser dialog. Depending on the distribution being used, there may be an unpleasant surprise once the files have been selected. Your editor, testing the Fedora hugin package, got a dialog containing the following:

If you see this message then your version of hugin has been configured without support for automatic generation of control points.

Probably your system administrator or Linux distribution did this because the SIFT algorithm used by autopano-sift and autopano-sift-C is encumbered by software patents in the United States of America.

Did your editor ever mention that software patents are a pain?

The message goes on to say that hugin remains a useful tool, even without the forbidden algorithm. And, indeed, it does, though the amount of work required is higher. The next step in the process is the assignment of "control points" which tie the images together. The tool presents a pair of images, and the user has the task of identifying points in each which [Control point selection] correspond to the same location. The process can be a little painful, depending on the images involved, but it's not that bad, especially if there are a lot of easily-identified, small features to line up. It's just a matter of clicking on one image, adjusting the point, then doing the same thing on the other image. Hugin creates a small, high-resolution window surrounding the selected points which makes it easy to align control points with single-pixel accuracy.

Once a couple of points have been fixed, hugin will do its best to automatically find the corresponding point for a location picked in one image. Often the process works quite well; other times, not quite so well. Sometimes hugin's guess is simply wrong; other times it will conclude that it cannot find a matching point and put up an obnoxious dialog which must be dismissed. In the latter case, it would be better to just pick a nearby point (as it does anyway) and be done with it. Beyond that, though, the process is pretty smooth.

[Hugin optimizer] Then, one must go into the "optimize" area. This is where the friendliness of hugin comes closest to falling apart. "Optimizing" is the calculation of a set of parameters describing how the component images are related to each other and how they have been distorted by the camera; it is, essentially, a set of magic algorithms generating magic numbers. A user who doesn't really understand the math behind what hugin is doing (and, remember, we're dealing with photographers here) will have no clue what's happening or how to judge whether the process has worked properly or not. And it doesn't always work properly. The help from the tutorials can make things worse:

If you are lucky you will be able to select Optimize Positions, View and Barrel (y,p,r,v,b), hit Optimize Now! and finish the optimisation process in one go. Otherwise, if the optimiser reduces the field of view to zero, you will find that you have to just Optimize Positions first, before you can optimise the other parameters.

How does one know if the optimizer has reduced the field of view in this way? The screen will not actually say that. So the optimizer is the place where a somewhat naive user (your editor, say) is likely to grope around blindly in the hopes of getting something done.

[Hugin preview window] After that, one can pull up the preview window to see what hugin plans to do with the images. The preview, too, can be confusing; mouse clicks on the image shift it around in ways which are entirely predictable (and even useful), but disorienting to a new user. Sometimes the program comes up with bizarre values for the actual area of the image, leading to a mostly black preview with the useful image data crammed into a corner somewhere. Solutions can include redoing the optimization process or going to the "stitcher" window and asking it to recalculate the image size parameters - including a couple of "field of view" numbers which don't have any clear meaning to the uninitiated. Things usually work, but it can be discouraging when they don't.

Once the preview looks good, the stitcher is invoked to create the final image. That process can take a while, but the end results tend to be good. Usually all that's required afterward is a quick cropping pass in a more traditional image editor to come up with something presentable. Here is your editor's final panorama (please note that the larger version is a 9MB image - and that's after reducing it considerably):

[Final panorama]

Your editor, being a daring sort of person, decided that he wanted to find out just what sort of functionality is being denied to hugin users by the oppressive US software patent regime. As it happens, Fedora users can get around patent-based repression by installing the autopano-sift-C package from the rpmfusion repository and tweaking the program preferences to use the real autopano tool. The difference is striking: with autopano-sift-C installed, the program proceeds immediately from image selection to a preview window; the whole "control points" and "optimization" process just sort of goes away. This package does a great job of finding control points, at least on your editor's sample image set. Software patents have cost Linux users a highly useful tool here; fortunately, users who are not affected by the American software patent regime can still obtain the autopano-sift-C package. Your editor would highly recommend doing so.

Beyond panoramas

Hugin's uses are not limited to the creation of panoramic images. The image distortion logic built into the program can be put to other uses as well. Consider this image from the 2008 Kernel Summit:

[Kernel summit before correction]

Your editor was constrained to take the picture from an off-center point of view - the professional photographer who was hired to do a proper picture had, naturally, taken the best spot. One might be tempted to point out that your editor's picture got out into the world, while the professional's has never really been seen, but your editor would never think of being so petty. What is worth pointing out here is that the off-center perspective, combined with lens distortion, results in a bit of a strange view; look at the visible bend in the beam at the top of the stage opening over the group of assembled kernel hackers. The sides of the opening also appear to not be parallel. It's a fairly classic case of distortion caused by the combination of an off-center perspective and a zoom lens being pushed to its wide-angle extreme.

It turns out that hugin can fix problems like this. To use hugin in this mode, the user feeds a single image to the application. The process of creating control points is now done a little differently; the task is to identify points in the same image which make up a horizontal or vertical line. Your editor indicated that the border around the stage really should be level and plumb, and picked a couple of other lines as well. Hugin then does its magic and comes up with a new image:

[Processed motley crowd]

The lines have been straightened and the photograph looks more rectilinear in general. It's still not perfect, of course, and not even hugin can make Al Viro smile, but it's a step in the right direction. This technique can be used for fixing up the perspective on any of a number of pictures which are taken from a less-than-optimal location.

In summary: hugin would appear to be unique in the free software community. Despite the occasional glitch, hugin makes the execution of non-trivial image manipulations easy to the point that even your editor can do it; your average professional photographer should have even less trouble. It is an impressive piece of work, even though it has not yet reached its 1.0 release (version 0.8 came out in July). It definitely belongs on any Linux-using photographer's system.

Comments (39 posted)

Netboot.me turns netboot into internetboot

September 9, 2009

This article was contributed by Koen Vervloesem

Recent computers support booting over the network by PXE (Preboot eXecuting Environment), an extension to the firmware that allows the computer to boot an operating system from a remote server using a network interface. However, this feature requires the user to setup a PXE boot server with one or more operating system images. A few weeks ago, Nick Johnson released a new service that makes use of PXE to boot into the install program of many popular Linux distributions and FreeBSD, directly over the Internet, and without the need of any local PXE boot server; it is called netboot.me.

Essentially, netboot.me offers a universal boot loader that allows the user to install the most recent version of any of a number of open source operating systems from one single medium. The boot loader makes use of gPXE (GPL PXE); the 1 MB image can be installed on a USB pen drive, floppy disk, or burned onto a CD. From then on, any computer that boots from the image retrieves the current list of available operating systems from the netboot.me website and shows that list in the boot menu. When the user chooses an operating system from the menu, the installer is downloaded over HTTP or FTP and starts running. This currently only works over an Ethernet connection, but WiFi support is in progress via a Google Summer of Code project for implementing 802.11 drivers in gPXE.

Currently the boot menu has installers for:

  • FreeBSD 7.2
  • Debian Lenny and Debian Testing
  • Fedora 11
  • openSUSE 11.1
  • Ubuntu 9.04 and 9.10 alpha

It also gives access to some live operating systems and tools that can come in handy. The user can launch live CDs for Tiny Core Linux 2.2, Micro Core Linux 2.2 and MirOS BSD. Other available tools are the [netboot.me menu] GParted Live disk partitioning tool, the Parted Magic 4.4 rescue and partitioning live cd, Memtest86 and Memtest86+ to test system memory, and Hardware Detection Tool, a Syslinux module that displays low-level hardware information.

So on the one hand, this boot loader gives the user the possibility to install some of the most popular Linux distributions and FreeBSD, without the need to first download and burn an installer image. On the other hand, the netboot.me boot loader has a couple of useful diagnostic, partitioning and rescue tools. Users often do not download rescue tools until they need them, at which point it may be too late, so the tools in the netboot.me menu can be a time—and system—saver.

Chainload URLs

Netboot.me refers to each available operating system by what the project calls a "chainload URL", which identifies the operating system image uniquely. For example, the Debian Lenny installer for x86 is located at the chainload URL http://netboot.me/2013. This web page lists the kernel image, the initial ramdisk, and the kernel arguments (vga=normal -- quiet). The details differ slightly among distributions, however: in the Fedora 11 PXE installer, the user has to explicitly enter a URL containing the Fedora installation image, while the openSUSE 11.1 installer already has the repository URL as a kernel argument. The netboot.me website lists the available operating systems in different subcategories.

In fact, the user doesn't even need the boot loader image: most recent computers are perfectly capable of netbooting without a boot disk. This can be used to automatically bootstrap a netboot.me boot loader which netboots the final distribution boot loader over HTTP or FTP. For such a diskless netboot, the user just has to change the settings of his local DHCP server to return the required information to boot over TFTP (Trivial File Transfer Protocol). Because TFTP isn't the most reliable protocol over the Internet, the user can also host his own copy of the bootstrap image on a local TFTP server. Instructions can be found on the Getting started page.

The best part is that netboot.me is hackable and open for contributions. Each user is able to add custom boot configurations to the website, although it unfortunately requires logging in with a Google account. The user then submits the URIs of the kernel image and initial ramdisk, together with any required kernel arguments. Netboot.me is capable of booting any Linux kernel and any other standard boot image, as well as disk images and CD images. To boot this custom configuration from the netboot.me boot disk, the user opens the gPXE command line with CTRL-B right before the netboot.me menu appears, enters autoboot and then chain http://netboot.me/XXXX with the correct chainload URL for the custom configuration.

Security

The security implications of netboot.me need to also be considered. What assurance does a user have that they are really getting the boot loader and OS image that were requested? In general, images on the netboot.me menu originate from either static.netboot.me, in which case Nick Johnson personally downloaded and verified them, or from official distribution web sites such as ubuntu.com. If the user trusts netboot.me and the official sources, the only remaining concern is man-in-the-middle attacks. Johnson calls this a legitimate concern and considers two components that could be secured further: the download of the scripts and menu from netboot.me, and the subsequent download of the boot image from the source. The former can be protected, in principle, by using SSL, which gPXE supports. Unfortunately, Johnson sees two major issues with gPXE's SSL support:

It doesn't do certificate verification, and its random number generator is poor (to say the least - it always fills the buffer with 0x01 bytes). Both of these can be fixed, of course (though getting legitimately random data at boot time is tough), but I have some reservations about the integrity of gPXE's SSL implementation and my ability to secure it. With that in mind, I'm considering a simpler approach: Sign responses from netboot.me with an RSA key, putting the signature in the header, and verifying it in gPXE. gPXE already has the RSA implementation, so in principle this is a fairly straightforward extension.

The second component (the download of the boot image) is somewhat simpler: securing it would require adding support for verifying content hashes of downloaded images. Most of this is already in place, actually, so according to Johnson this would be a very simple extension.

Host your own netboot.me

The code for netboot.me is licensed under the BSD license. Most of the server side is Python code which is meant to run on Google App Engine. The boot loader is a modified version of gPXE. One obvious disadvantage of netboot.me is its dependence on Google App Engine. While there aren't any active efforts to decouple netboot.me from the App Engine, Johnson maintains that this ought to be fairly straightforward:

Netboot.me doesn't use the datastore in a particularly complicated manner, so it ought to be fairly easy to insert an abstraction layer to allow it to run on a relational database. Alternately, there are efforts like AppScale and Twisted AE to make it easier to host App Engine apps in third-party environments. For a purely local network solution, however, hosting using the SDK's dev_appserver would probably be perfectly satisfactory.

Collaboration

How does netboot.me compare with other solutions? There is Billix, a multiboot USB pen drive with network installations for several Linux distributions. Its approach is different: Billix hosts network install ISOs of the distributions on the USB pen drive, while netboot.me bootstraps the user's computer to grab complete ISOs of the distributions via PXE over the internet.

Another more direct competitor of netboot.me is boot.kernel.org (BKO), which is a Google Summer of Code project for gPXE. Although it seems to be less polished than netboot.me and offers fewer Linux distributions at the moment, it has one advantage: it can be installed easily on a local server. The administrator can download the ISO images, and then all users on the local network then can install the available Linux distributions via PXE. Because the ISOs are stored on the local network, this goes much faster than over the internet with netboot.me. This is not a luxury because the experience with netboot.me regularly gets spoiled by slow downloads of the operating system images.

The projects also have a slightly different focus. BKO is aiming more at live distributions that use iSCSI or HTTPFS for mounting filesystems, while netboot.me is concentrating more on netbooting existing images. According to Johnson, the two projects are keeping an eye out for opportunities to collaborate. As part of that effort, he has already added a menu item in the "Tools" category that loads the boot.kernel.org menu from within the netboot.me menu.

In conclusion

For testing out new distributions—or entire operating systems—it is certainly convenient to be able to boot directly from the internet. But, for system recovery tasks, it could easily be indispensable. Being able to access any number of up-to-date distributions, live CDs, and recovery tools, without having to maintain a library of CDs or other media, is something that users and system administrators alike may find very handy.

Comments (5 posted)

FUD at Best Buy

By Jonathan Corbet
September 9, 2009
In many parts of the US, the Best Buy chain is truly the best bricks-and-mortar option for those looking for electronics and related products. That is seen by many as a rather sad state of affairs, but such is life; we can't all live in Akihabara. It is not a place where one normally goes in search of technical expertise. Recent reports that Microsoft has made an attempt to make the situation even worse should not be particularly surprising - or concerning.

Recently, a Best Buy employee encountered some Microsoft training materials aimed at Best Buy sales people. Surprisingly enough, Microsoft would like these sales representatives to believe that Windows is a better operating system than Linux; Microsoft would also be most gratified if those representatives would convince their customers of the same. So it has put together a set of slides full of easy-to-remember sales points and gotten Best Buy to use those slides as training material.

So why is Windows better? Apparently it offers a "richer and more engaging experience." It is, believe it or not, compatible with Windows, which is seen as a good thing. There is, we're told, better support for cameras, iPods, printers, and more. Windows Live stuff is not supported under Linux; neither is World of Warcraft. Best Buy employees are to tell their customers that Linux lacks "authorized support," it takes a lot of time to maintain and it doesn't offer "regular updates." There's no guarantee of security updates; "Linux users are on their own." There are no "step-by-step tutorials" for Linux.

Some of Microsoft's claims have merit: it is almost certainly true that Windows users are more familiar with Windows than with Linux, for example. Others are clearly false. It's amusing to see the return of the "no support" FUD line - though it must be said that the support options available to an end user who buys a Linux-based netbook from Best Buy are limited. The "Geek Squad" is likely to prove a disappointing resource for confused Linux users. There is no mention that World of Warcraft can be run under WINE, but one should also bear in mind that there's probably no end of WoW junkies who have no interest in trying to figure out a Wine installation. Cameras work fine with Linux, as do music players, and printers are getting better all the time. The security claims still come across as laughable. It is clear that Microsoft is clearly playing a little loose with the truth here.

The response on the net has been strong; Microsoft's attempt at Best Buy sales droid indoctrination appears to have touched a sensitive nerve. The Linux community does, indeed, show a high level of sensitivity for this kind of criticism. It has been years since Linux was dismissed as a toy operating system which was not to be taken seriously, but, perhaps, we still have some sensitive toes left from those days.

But think about it: it's a rare corporation which does not attempt to make its products look better than those of its competitors. It's also a rare company which does not stretch the truth occasionally in the process. Lies and FUD are not justified, but they are normal. The fact that these techniques are being turned against Linux at this level is not particularly surprising. It just says that Microsoft sees Linux as a true competitive threat in need of the usual competitive response. Linux is being treated like just another competing product on the market.

Much effort has gone into publicizing and debunking Microsoft's training slides. It is worthwhile to shine light on this kind of activity, and it is worthwhile to correct claims that are not true. But Microsoft's silly training slides are not a cause for great concern, hang-wringing, or outrage. They are just another ham-fisted attempt to fight off an increasingly worrisome competitor. As long as Microsoft keeps its fight on this level, we have little to worry about.

Comments (38 posted)

Page editor: Jonathan Corbet
Next page: Security>>

Copyright © 2009, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds