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 <[email protected]> > 2009/9/20 John Robert Peterson <[email protected]>: > > 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 > [email protected] > http://lists.openstreetmap.org/listinfo/talk-gb >
_______________________________________________ Talk-GB mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-gb
