[Talk-GB] Stitching Aerial Photographs

John Robert Peterson jrp.crs at gmail.com
Sun Sep 20 23:28:22 BST 2009


I now understand how you managed to put together that set of images so
perfectly -- and the limitation that it can only be done with a set of
images taken from the same point.

you are indeed correct that I was straffing the camera from as close to
vertical as the window of the plane allowed, up to where I felt was useful
(usually 3 images, somtimes 2, ocasionally as many as 5), overlapping them
by around 50%, or as close as I could manage (sometimes I wasn't even
looking through the viewfinder, I was just moving the camera about as far as
I'd moved it last time)

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.

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?

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?

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?

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

JR



2009/9/20 Matt Williams <lists at milliams.com>

> 2009/9/20 John Robert Peterson <jrp.crs at gmail.com>:
> > ok -- now we are getting somewhere -- this is awesome.
> >
> > I would sugest rectifying against the gps trace data, not the map layer,
> > because the positions on the map later are derived, introducing slight
> > inacuracies.
>
> That would be a good idea. I'm never quite sure what map features I
> can rely on to be accurate. Having gps traces as a layer would make
> things more accurate and reliable.
>
> > Do we have anything that will draw map tiles of the trace data? (I'd like
> > this for another project anyway: checking whether traces exist for an
> area
> > when out with a mobile device)
> >
> > now hugin/panarama tools/sift has a strong concept of control points, so
> > does warper -- is there any way that we could get them to use the same
> > points, and bolt the 2 together automatically?
> >
> > nearly a week ago I posted the following, any further thoughts on it:
>
> <I'll respond to this in another email>
>
>
> Now that I'm getting more used to the idiosyncrasies of Hugin and co.,
> I've worked out a workflow that creates usable images. It seems that
> Hugin is _very_ sensitive to trying to stitch together two images that
> weren't taken from the same point in space (or for our purposes,
> anything more than the distance travelled by a plane in 30 seconds or
> so). This means that an image of a village taken from the north (i.e.
> camera facing slightly south) cannot be reconciled with an image of
> the same features taken from the south (camera facing slightly south).
>
> However, there is still stitching we can do. John's method for many
> parts (or at least the bits I've analysed so far) seems to have been
> to strafe the camera from near-vertical to ~45° with overlap between
> the images. The images within each of these sequences can be stitched
> together (i.e. 804-804, 805-808, 809-812 etc.) and those composite
> images rectified. Perhaps it's worth skipping the more oblique images
> from the stitching to avoid them being on the same 'layer' as the good
> vertical ones.
>
> My workflow in Hugin to create each composition is:
> 1. Find a series of images which belong to one sweep of the camera
> (e.g. 805-808)
> 2. New Hugin project - Go to Images tab
> 3. 'Add Individual Images' and select the images you need
> 4. Select them all and click 'Create control points' button at the
> bottom (you need panotools-swift-c for this)
> 5. Once it's created the points, go to Optimiser tab, Choose
> 'Positions (incremental, starting from anchor)' and optimise and
> accept.
> 6. Then Optimise again but with 'Everything' selected in the drop-down
> 7. Stitcher tab: Projection = 'Mercator', click 'Calculate field of
> view' then 'Calculate optimal size'
> 8. Choose TIFF compression LZW and 'Stitch now!'
>
> This should create a nice composite image ready for rectifying.
>
> --
> Matt Williams
> http://milliams.com
>
> _______________________________________________
> Talk-GB mailing list
> Talk-GB at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-gb
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-gb/attachments/20090920/fd544201/attachment-0001.html>


More information about the Talk-GB mailing list