|
|
Subscribe / Log in / New account

The Grumpy Editor's hugin experience

Did you know...?

LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net.

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.


(Log in to post comments)

0.7.0

Posted Sep 8, 2009 17:18 UTC (Tue) by ametlwn (subscriber, #10544) [Link]

From the screenshots this looks like the review was done on 0.7.0 (missing [OpenGL preview] button).

0.7.0

Posted Sep 11, 2009 16:43 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link]

For whatever reason, Fedora 11 hasn't upgraded to 0.8 yet; that's only available in Rawhide.

The Grumpy Editor's hugin experience

Posted Sep 8, 2009 18:24 UTC (Tue) by miekg (subscriber, #4403) [Link]

This is why I love lwn.net. Just today I discovered hugin - as I also needed to create a panorama.

Flipping over to lwn - bam! A nice review.

Distortion correction

Posted Sep 8, 2009 20:21 UTC (Tue) by man_ls (guest, #15091) [Link]

Distortion correction is a very interesting area, and it is growing more interesting each day. Consider new cameras like the interesting Olympus E-P1: it has pretty sucky optics, but performs distortion correction in software. Other makers are integrating correction of aberrations in the software. This has a few interesting consequences:
  • Makers can spend less in lenses and do difficult things, like ultra-flat optics.
  • A firmware update can include better compensations, therefore improving your image quality -- like if you bought a better lens.
  • OTOH bugs in firmware can mean bad image quality in certain lenses (see the 17mm f2.8 fiasco).
  • If you export images in RAW format (i.e. without transforming into JPEG), you get the original with all the distortions.
  • Since only the Olympus software has the parameters to do the corrections, third-party image editors (i.e. those available for Linux) will leave ugly distortions.
This last point is where software like hugin can find another niche: photographers wanting to do their own corrections to pictures. Of course it is much easier to do them in-camera, since you have access to raw pixels, and they are not trivial transformations -- distortions can be compensated with just the kind of thing our editor has tried here, but chromatic aberration correction requires separating components, correcting for different distortions for each color, then mixing it all again. But it is a start.

Distortion correction

Posted Sep 9, 2009 14:16 UTC (Wed) by kenmoffat (subscriber, #4807) [Link]

Doh! Thanks for that. I use an Olympus E510 - last year I eventually became aware of barrel distortion in some of my photos taken with the 18-42 at wider-than-standard (<25mm). I managed to adequately correct some of them in the gimp (apply negative lens distortion), but my attempts to fix others didn't look better or worse, just different.

Meanwhile, now I was aware of the problem I took some more pictures, using the older, and bigger, 18-45 from my E500. In those I became aware of the distortion in-the-viewfinder on some pics, which is very disconcerting.

After that, I took a series of pics with all my lenses at various lengths and apertures. Used 'display' from ImageMagick to quickly review these, but I couldn't see _any_ significant distortion. By now, my brain was starting to hurt, and I began to doubt my eyesight (and discarded those test pics).

Now I've read your comment, and compared one pic where I remembered mild barrel distortion - sure enough, the raw (.orf) shows it, but olympus's own jpeg is corrected. Thanks again, I'm off to take some more test pics.

ken

Distortion correction

Posted Sep 17, 2009 6:09 UTC (Thu) by eduperez (guest, #11232) [Link]

Only that all those corrections reduce the quality of the image: as you move pixels all around the image, some of them do not fit exactly into their final destination, and must be interpolated; even a simple horizon correction thrashes away some quality.

The Grumpy Editor's hugin experience

Posted Sep 8, 2009 21:58 UTC (Tue) by qg6te2 (guest, #52587) [Link]

the SIFT algorithm used by autopano-sift and autopano-sift-C is encumbered by software patents in the United States of America.

As an alternative to the SIFT algorithm, perhaps the authors of the software might be interested in the SURF algorithm. It accomplishes essentially the same task (feature point detection and description in images).

that's patented too :-(

Posted Sep 9, 2009 0:59 UTC (Wed) by coriordan (guest, #7544) [Link]

This comment say that SURF is patent encumbered too :-(

(If anyone has more data or better links, I'm documenting this and any help'd be appreciated.)

that's patented too :-(

Posted Sep 9, 2009 17:41 UTC (Wed) by PO8 (guest, #41661) [Link]

Yes, SIFT (US Patent 6,711,293) is patent encumbered. Since the patent holder is the University of British Columbia, it would be nice if someone tried talking to them about licensing the patent free of charge for open source programs; I don't know if anyone has done that yet.

While it has been widely claimed that SURF is also patented, I cannot seem to find an actual patent or application. It is possible that the SIFT patent covers it, since they are similar methods and the SIFT claims are fairly broad.

I'm currently working with a student on something that might or might not avoid these and other microfeature patents and work OK. Other feature description algorithms listed by Wikipedia include Canny, FAST, SUSAN, GLOH, and LESH. I do not know much about the quality and patent status of these algorithms.

that's patented too :-(

Posted Sep 10, 2009 10:05 UTC (Thu) by drnlmza (subscriber, #60245) [Link]

The hugin people have been using google summer of code projects to develop a patent-free solution. The last good overview of the status I've seen is the discussion in the "What is the status of keypoint detection and keypoint matching: machpoint (gsoc2007) and feature_matching (gsoc2008)" thread (http://groups.google.com/group/hugin-ptx/browse_thread/th...), from especially the comments by Pablo d'Angelo (http://groups.google.com/group/hugin-ptx/msg/b6a0ac936af1...).

The Grumpy Editor's hugin experience

Posted Sep 9, 2009 0:04 UTC (Wed) by aigarius (guest, #7329) [Link]

As the author of several Debconf group photos I have two pet pieves with hugin (along with the ones the editor already highlighted):
* Hugin has a tendency to twist faces into ugly shapes. Take a group photo of 5x5 images and have a person be near the corner in several images. There is a good chance that such a person will end up with half a face from one photo, third of a face from another photo and a small corner above the left eye from another photo resulting in a convulsed and twisted face, distorted beyond recognition. People moving and turning their heads ever so slightly complicates this even further. Face detection technologies could help here.
* The way that I usually try to fix the above bug is to take the final photo and paste over faces for the unlucky people - I cut from transformed but unmerged images over the final rendering. This would have been much easier if hugin could have allowed some sort of editable export option like a layered GIMP file where I would be able to adjust the blending.

Oh, and it creates temp files in /tmp regardless of the configuration setting, so be sure to have enough RAM for really large panoramas like the 98Mpix Debconf 9 group photo I made with hugin earlier this year ;)

Controlling face overlays from different photos

Posted Sep 9, 2009 3:35 UTC (Wed) by hannada (guest, #4633) [Link]

Hugin does provide a fairly simple mechanism for controlling situations such as the one you describe (where different pieces of images of faces are inappropriately combined from different images). This method requires that the images be in a format that provides an alpha channel to control transparency. In my case, I

1) Converted the original images from JPEG into PNG. (JPEG seems not to support alpha channels).
2) Used GIMP to activate an alpha channel layer for the image.
3) Used GIMP to "paint" the alpha channel layer "off" (fully transparent) for the parts of the input images that I wished to exclude from the final merged image.
4) Export the modified image as a PNG file (large, but temporary), then built the final panorama from these modified images.

In this way, I was able to select which of the redundant image elements would be excluded and eliminate the "chopped image" appearance that you describe. Note that this feature is strictly "on" or "off". Gradations in the alpha channel are ignored.

Controlling face overlays from different photos

Posted Sep 10, 2009 20:47 UTC (Thu) by roelofs (guest, #2599) [Link]

1) Converted the original images from JPEG into PNG. (JPEG seems not to support alpha channels).

JPEG/JFIF doesn't, but JPEG/JNG does (e.g., see libmng). It's not widely supported, though.

However, for what you're doing--multistage image editing--you want PNG or some other lossless format anyway. Switch back to JPEG only at the very end.

Greg

The Grumpy Editor's hugin experience

Posted Sep 9, 2009 0:53 UTC (Wed) by leromarinvit (subscriber, #56850) [Link]

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.

Just wanted to reinforce that - hugin and autopano-sift are awesome. I just created a panorama (disclaimer: huge JPEG) from a bunch of photos I took 5 years ago with the intention of stitching them together, but never actually did - until today.

These are handheld photos, and I obviously had to move around taking them, on uneven terrain. Also, the FOV is almost 360°. Parallax? You bet. All told, I think the end result is quite a feat, and the only manual step involved was cutting the black borders away afterwards.

The Grumpy Editor's hugin experience

Posted Sep 14, 2009 1:53 UTC (Mon) by wookey (guest, #5501) [Link]

Yep. I discovered this tool a little over 3 years ago, and every time I come back to use it again it's got a load better. It was quite hard work to work out how to drive it originally given my (like the editor) abject lack of knowledge of stitching and image distortion and the terminology surrounding them, so when it asked if I want to enable 'enlend' or 'autopano-sift', I had no idea whether I wanted those or not, nor did I know if I wanted 'rectilinear' or 'barrel distortion' or 'mercator projection' and so on.

I was quite amazed how well it works on a not-at-all consistent (due to water movement) image: http://wookware.org/pics/mexico/img000.jpeg.html

But now you get a nice viewer thingy of the result so it is trivial to just say 'what does it look like if I ask for one of these'. And the auto-point selection is a huge boon.

The only thing I really wish it could do better is the merginging of differently-exposed blank colour areas - that generally means blue skies. Many of my efforts to date end up with nasty staircase artifacts in the sky at the joins. I guess this has a lot to do with the JPEG compression of the originals ?, but a smidgen of blurring at the joins would make it so much better (at least for the 'average user'). Here's an example of the issue:

http://wookware.org/pics/jtrocks.jpg (1.6MB jpeg)

Hugin is marvellous. Kudos to the developers. gthumb is great too. Now if someone can just make the HDR tools this easy to drive my photography requirements will be entirely met.

The Grumpy Editor's hugin experience

Posted Sep 14, 2009 2:56 UTC (Mon) by knobunc (guest, #4678) [Link]

Hm. How are you stitching your sky image? Enblend does clever things to try to solve that:
http://enblend.sourceforge.net/details.htm

The Grumpy Editor's hugin experience

Posted Sep 14, 2009 19:49 UTC (Mon) by wookey (guest, #5501) [Link]

Thanx for that link: very interesting. Now I know it's supposed to deal with this problem I'll try a bit harder next time I see it. That image was done quite a while ago, so I guess enblend was missing from Debian at the time, or I had is disabled or something? It has been a while since I saw nasty artifacts so it's probably just working now. Like I say, every time I come back it seems to work noticeably better.

Some panorama tips and a correction

Posted Sep 9, 2009 12:44 UTC (Wed) by anton (subscriber, #25547) [Link]

I have used hugin 0.7 for a while with the autopano-sift stuff. In some cases it had troubles finding correct control points (e.g., in the sky with moving clouds or on water). In these cases I often had success by just removing the wrong control points and letting it work again.

I usually use exposure bracketing for my photographs. A cool feature of hugin is that I can throw all the different exposures of the component pictures into it and it will produce a nice panorama; I can choose the exposure right at the end.

Hugin can also be used to produce high dynamic range pictures from different exposures of the same szene, but I am still missing a good program that then compresses the high dynamic range again into a good-looking normal-dynamic-range image (often called tone mapping) for display.

Despite the coolness of hugin, I currently use Microsoft ICE for doing panoramas, and it's the only non-game program I run on Windows; it's significantly faster than hugin and has an even higher rate of success without manual intervention. But I miss being able to control the exposure of the result, and it's proprietary.

The problem with just gluing two images together is simple to understand: lenses distort.
Nitpick: The ideal lens projects a rectangle onto a rectangle (rectilinear projection), and then one usually does not say that it distorts. However, the rectangles of the images you want to glue together have a different orientation, so they need to be transformed in order to match even if the lens is ideal.

Some panorama tips and a correction

Posted Sep 10, 2009 4:24 UTC (Thu) by eru (subscriber, #2753) [Link]

Nitpick: The ideal lens projects a rectangle onto a rectangle (rectilinear projection), and then one usually does not say that it distorts.

But isn't it so that the lenses in real-life cameras are never quite ideal? I believe the only realizable camera that does not have any geometric distortion is the pinhole camera.

Some panorama tips and a correction

Posted Sep 10, 2009 9:27 UTC (Thu) by anton (subscriber, #25547) [Link]

But isn't it so that the lenses in real-life cameras are never quite ideal?
That may be true, but misses my point, which was that a panorama program has to transform the component images even if the component images are not distorted.

Photoshop Elements

Posted Sep 9, 2009 14:10 UTC (Wed) by scripter (subscriber, #2654) [Link]

Although it's not free software, Adobe Photoshop Elements is an excellent commercial tool for stitching together photos into a panorama.

Photoshop Elements

Posted Sep 11, 2009 10:31 UTC (Fri) by wookey (guest, #5501) [Link]

That may be so, but isn't it almost completely irrelevant here? Why would this readership care that a proprietary alternative existed to their very good Free Software tool? Does photoshop even run on linux? (Can you tell I've never tried).

The Grumpy Editor's hugin experience

Posted Sep 10, 2009 8:04 UTC (Thu) by Thue (guest, #14277) [Link]

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.

From that I assume the 2008 Kernel Summit bought the photographic equivalent of proprietary software, when they should have ensured they got the rights to modify and distribute the photograph, as well as the "source code" (high-quality digital image file). (photographers usually sell their time cheap, and then get their money from selling copies of their photographs separately)

Ironic...

The Grumpy Editor's hugin experience

Posted Sep 10, 2009 9:09 UTC (Thu) by rwmj (subscriber, #5474) [Link]

I'll pimp my canal photo [warning: large], done with Hugin + autopano-SIFT on Fedora using the non-free rpmfusion repo.

The Grumpy Editor's hugin experience

Posted Sep 10, 2009 18:07 UTC (Thu) by dag- (guest, #30207) [Link]

While I found the article interesting, it was the Al Viro comment that made me smile. It hasn't worn off yet ;-)

The Grumpy Editor's hugin experience

Posted Sep 17, 2009 2:23 UTC (Thu) by donbarry (guest, #10485) [Link]

Please also recall that hugin is primarily a frontend to tools developed
almost ten years ago (panotools, libpano, etc) by Dr. Helmut Dersch at the University of Furtwangen. A lawsuit over patents related to panoramic imaging by IPIX (now belovedly bankrupt) made him take down his pages and spend years underground with the lawyers doing the talking while others kept the sources available in a sort of ghetto existence. Development of these tools and front-ends like Hugin were enormously slowed by the FUD surrounding this at the time. Even now, Dr. Dersch's renewed presence on the web and in the development process seems gun-shy -- and who could blame him?

The Grumpy Editor's hugin experience

Posted Sep 17, 2009 8:59 UTC (Thu) by renox (guest, #23785) [Link]

The 2008 Kernel Summit image isn't still very good: before the line at the feet of the first row is horizontal after it's tilted, either it's a configuration issue or an issue with the tool..

The Grumpy Editor's hugin experience

Posted Sep 20, 2009 2:47 UTC (Sun) by asdlfiui788b (guest, #58839) [Link]

I'm surprised nobody mentioned that hugin uses Mono. I discovered that
when I got rid of Mono on my Kubuntu system--it took hugin with it. Surely
everyone by now knows about the Mono controversy. It's tainted by the
Microsoft/Novell agreement. Your tinfoil-hat size may vary.

Mono?

Posted Sep 20, 2009 4:08 UTC (Sun) by corbet (editor, #1) [Link]

Don't know what Kubuntu has done, but, on my Fedora box, hugin has no dependency on mono.

Mono?

Posted Sep 21, 2009 9:48 UTC (Mon) by mp (subscriber, #5615) [Link]

Most likely they use the C# autopano-sift instead of the C port.

The Grumpy Editor's hugin experience

Posted Sep 20, 2009 7:48 UTC (Sun) by Cato (guest, #7643) [Link]

I just checked on Ubuntu 8.04 and there's no mono dependency for hugin, hugin-bin, hugin-tools, etc.

For the anti-mono crowd, here's a handy command:

# aptitude why mono
No justification for mono could be constructed.

The Grumpy Editor's hugin experience

Posted Sep 22, 2009 10:30 UTC (Tue) by mikecalder (guest, #60928) [Link]

That surprised me - I've had to stop using hugin for a couple of years or so because of the Mono requirement. Every update of Ubuntu I get, I check again.

I'm using the latest version of Ubuntu, 9.04.

I checked again after you said Ubuntu 8.04 dosn't need Mono (which was not my recollection).

If you're right on Ubuntu 8.04, sorry, but you're wrong on 9.04. Telling Synaptic to install hugin pulls in all the Mono cruft. I have a 64 bit machine, but the 32 bit packages can scarcely be different, can they?

If someone, somewhere, can put together a package or install script that lets me use hugin without Mono, I'll use it.

Until then, I'm continuing to use a Windows package under Wine.

The Grumpy Editor's hugin experience

Posted Sep 22, 2009 11:18 UTC (Tue) by nye (guest, #51576) [Link]

>Until then, I'm continuing to use a Windows package under Wine.

It seems a little incongruous that you're happy to use Wine, but not mono :P.

That said, it does seem a little brain-damaged that Ubuntu have decided to make a required dependency on what should be an optional package, and one for which a C version already exists, no less.

Anyway, your options probably aren't great for running outside Wine: you could install the Debian version of the package, which would mean that you then need to get autopano-sift-c from debian-multimedia, or you could build from source - it may be possible to build from the Ubuntu source package but not include the C# autopano-sift (not sure).

Or you could just continue using Wine. Performance does suffer a little - probably mostly because it's 32-bit - but you're not missing out on a great deal (except that it's butt-ugly :P).

The Grumpy Editor's hugin experience

Posted Sep 24, 2009 13:53 UTC (Thu) by mikecalder (guest, #60928) [Link]

>It seems a little incongruous that you're happy to use Wine, but not mono :P.

Not at all; they're quite different animals.

Wine allows you to continue to run legacy applications for which no current new open source alternative exists.

Mono is for new code to be written that runs on Windows.

So Wine allows you to get away from the evil while still having the nasties that can't be changed just yet, while Mono only allows you to create new evil. ;-)

The Grumpy Editor's hugin experience

Posted Sep 22, 2009 18:32 UTC (Tue) by khc (guest, #45209) [Link]

Looks like hugin depends on hugin-tools which suggests autopano-sift, which requires mono. Since hugin-tools only suggests autopano-sift, you can remove autopano-sift (and mono) afterward, or configure apt to not install suggested packages by default.

The Grumpy Editor's hugin experience

Posted Sep 23, 2009 10:58 UTC (Wed) by nye (guest, #51576) [Link]

I'm not sure what hugin packages you're looking at, but they aren't the ones in the Ubuntu repository, unless packages.ubuntu.org is providing incorrect dependency information.

The Ubuntu hugin package depends on autopano-sift, for which only the mono version exists.

(And FWIW, apt doesn't install suggested packages by default, though I believe it does now install recommended packages by default.)

The Grumpy Editor's hugin experience

Posted Sep 23, 2009 21:28 UTC (Wed) by khc (guest, #45209) [Link]

In 9.04:

$ apt-cache show hugin | grep Depends
Depends: hugin-tools (= 0.7.0-1ubuntu2), enblend (>= 3.2), enfuse, libimage-exiftool-perl, make, autopano-sift, libboost-thread1.34.1 (>= 1.34.1-8), libc6 (>= 2.4), libgcc1 (>= 1:4.1.1), libpano13-0, libstdc++6 (>= 4.2.1), libtiff4, libwxbase2.8-0 (>= 2.8.9.1), libwxgtk2.8-0 (>= 2.8.9.1)

$ apt-cache show hugin-tools | grep -E 'Depends|Suggests'
Depends: hugin-data (= 0.7.0-1ubuntu2), libboost-thread1.34.1 (>= 1.34.1-8), libc6 (>= 2.4), libexiv2-5, libgcc1 (>= 1:4.1.1), libilmbase6, libjpeg62, libopenexr6 (>= 1.6.1), libpano13-0, libpng12-0 (>= 1.2.13-4), libstdc++6 (>= 4.2.1), libtiff4
Suggests: autopano-sift | autopano-sift-c

And apt-get install of hugin asks me to install autopano-sift.

The Grumpy Editor's hugin experience

Posted Sep 24, 2009 12:52 UTC (Thu) by nye (guest, #51576) [Link]

I think there's one part you didn't notice:

>$ apt-cache show hugin | grep Depends
>Depends: hugin-tools (= 0.7.0-1ubuntu2), enblend (>= 3.2), enfuse, libimage-exiftool-perl, make, autopano-sift, ...

So hugin depends on autopano-sift, and the fact that hugin-tools also suggests it is not relevant.

The Grumpy Editor's hugin experience

Posted Nov 6, 2009 13:02 UTC (Fri) by mikecalder (guest, #60928) [Link]

The Hugin website has a page describing in detail the commands needed to install Hugin (actually, compile from scratch) specifically for Ubuntu. It does not need, or even discuss, Mono. I've now don this successfully on both Jaunty and Karmic, and am a happy Ubuntu Hugin user.

Apparently the Hugin developers are very happy to work with a C version of Autopano-sift and see no reason to pull in the additional overhead of Mono.

One wonders why Ubuntu has added it.


Copyright © 2009, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds