view all posts by Greg Lehey

More fiddling with Hugin

Greg Lehey Posted by Greg Lehey | Sat, 23 Feb 2013
see the original posting from Greg's diary

So it seems that I will need to install wxWidgets 2.9 to have a chance of setting multiple displays, and even then it's not clear that it will work. But maybe there's an easier way: Hugin honours the DISPLAY environment variable, so how about setting that inside the program, before the window is created? Did thathow easy C is in comparison to C++but it had no effect. Presumably the widgets, or possibly GTK+, have looked at the variable on startup and hidden it somewhere difficult to find. That was to be expected, but I wonder how much sense it really makes? The idea of Object-oriented programming was to make things simpler, not more difficult.

Today was also house photo day, so I had my first opportunity to try the new version of Hugin in earnest. It didn't do well: the stitcher died without any message. And when I saved my projects, I discovered that they had spaces in the file names! The current version of Hugin gives a default project file name something like 00-19.pto, where 00 and 19 are the first and last image numbers. But now that's been changed to 00 - 19.pto. Vomit! And as a result, my scripts hadn't saved them.

So back to the old version. Today was anything but an ideal day for the photos: cloudless sky and bright sunshine. And it's becoming clear that I need to reconsider how I take these photos. In principle using automatic exposure for the component images works wellif the difference in brightness isn't too big. When it is, things can look less good. In these two consecutive images, the exposure differs by 1.7 EV, and the sky looks completely different:

This should be garden-se-2.jpeg.  Is it missing? This should be garden-se-3.jpeg.  Is it missing?

Surprisingly, enblend does quite a good job of merging the images:

This should be garden-se.jpeg.  Is it missing?

Still, I need to pay more attention to the skies, which in general didn't look too good this week.

One other thing that I discovered while processing the abortive Apollo Bay beach panorama: I accidentally took the first image at 17 mm focal length, and the others at 12 mm focal length. I had intended to discard the first one, but the control point detectors fitted it correctly, so I tried stitching it anyway to see what would happenand it worked! This is a more extreme example of the image alignment problems I described earlier this month. When I first tried it I had no success at all: the control point detectors couldn't work it out. What has changed? I wish I knew. But today I tried another one: the verandah east panorama has an issue with the exposure of the Hebes to the left of centre, which are in the shade. So I took the entire panorama with a focal length of 9 mm, and then just the shadow part of the Hebes at 18 mm. And Hugin had no difficulty aligning them:

This should be Image-alignment.gif.  Is it missing?

Clearly there's much room for experimentation here.

And yet another discovery: I have been using the panomatic control point detector, because it seemed to work better than CPFind, but today it failed on two panoramas. Tried CPFind, and it had no difficulties. There's something very strange about these control point detectors.

see the original posting from Greg's diary

Back to top