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:
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
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.
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.
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):
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:
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:
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)
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
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)
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>>