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