[Talk-GB] Stitching Aerial Photographs

Matt Williams lists at milliams.com
Mon Sep 21 12:57:28 BST 2009

2009/9/20 John Robert Peterson <jrp.crs at gmail.com>:
> I learned from some attempts at making panoramas (using hugin) in the past,
> that it's good to have a wide overlap, I always try for a little more than
> 50% so that if one image fails, the 2 next to it can fill in the gap at a
> pinch.

Yes, this has certainly helped. autopano-sift-c does a good job with
the images you took so the overlap is fine.

> the problem with assuming that the images taken in one strafe are from the
> same position is -- they are not taken from the same position -- the plane
> was moving at 100kts (50ms^-1) and the strafe took about 1-2 seconds, so the
> source position could have changed by as much as 100 meters. this could have
> 2 problems -- it could cause issues when rendering a single strafe -- this
> seems not to be a big issue though. I could also cause compound issues when
> multiple strafes are ligned up next to each other.
> Now is there any way that we can get hugin to not be fussy about the source
> point of the images?

Reading the link (http://www.dojoe.net/tutorials/linear-pano/) given
by Axel, it seems it is possible to reduce this problem by unchecking
both the 'Link' boxes under 'Image Center Shift' for the photo lens in
Hugin. This gives the optimiser more freedom where it is needed.

> is there any way that we can use hugin in a distributed way? your idea of
> using a map layer as one of the images is inspired BTW :)
> can hugin be set up so that it uses mercator as the projection, and so
> understand that the whole planet is spherical?

I've been using Mercator as the projection under the Stitcher tab but
I'm unsure if that means that it knows to project the composite image
as Mercator.

I think I've found an effective way to use OSM map images within Hugin
though. First get a map image from OSM via the export tab (or
something), then load it as an image in Hugin (guess a focal degrees
of view of 10 when importing it). This map image should have a
different Hugin lens number to the other images. Set the map as the
"anchor for position" and do whatever control points you need and
optimise positions (incremental) and then y,p,r,v,b. I the stitcher
tab, set the output to be 'remapped images' rather than 'blended
panorama' to just get the rectified images. Now, we could put these
into Warper individually but to combine them into one image, do
'enblend -o fooblendoutput.tiff foo0001.tif foo0002.tif
--compression=LZW' (or whatever the image names of the images
excluding the map are. The map should be foo0000.tiff). This should
give you an _almost_ geo-rectified image but it should recify easily
in Warper. However, even with this, I'm still getting divergence at
the edge of the image due to lack of ground control points there. I
may have to try it in a more urban area to find more mapped ground
control points.

If anyone else wants to have a play, post your results here.

> can indevidual map tiles be loaded as indevidual images? automatically? (if
> optimisation is turned off for them this will have no significant
> performance issue)
> is there any way that I can get hugin's SIFT algorythm running on the full
> size images here, and publish the resulting points to save others processing
> power and time?

Probably, yes. The algorithm is a separate application called
autopano-sift-c which should just run over the images. However, the
coordinates will be in terms of pixels and so will not match up to the
smaller images.

> could we deduce form this data which images overlap with each other?

Yes, I think autopano-sift-c can do that(?).

In the mean time, I'm having a play with bundler since at the very
least it should be able to approximate the location of each camera
shot in real 3D space. The paper Kai posted (which is exactly what we
need to do btw) says that they used bundling algorithms to help them.

I also note that in the paper, they managed to take (more) vertical
photos by sticking the camera out a loading door at the side of the
plane on a mounting so that the camera could always face straight
down. Worth bearing in mind for the future?

Matt Williams

More information about the Talk-GB mailing list