Hi Matt, The general workflow for "proper" orthorectification (as used by the professionals) is:
1. Measure some ground control points (GCPs) in the images. These associate an image point with a 3D world position (lat, lon, height). If a full bundle adjustment is used, this is not needed for every images as tie points (called control points in hugin) can also be used. These are usually measured against maps, orthoimages, gps traces. The height is often derived from the SRTM dataset, or from high precision GPS measurements with post processing at specific corner (centre of roundabouts etc.). 2. With the GCPs and tie points, the position and orientation of each photo is estimated using bundle adjustment. This works a bit similar to what hugin/panotools does, but it solves for full 3D geometry. 3. Orthorectification is preformed using the estimated positions and orientations and a digital terrain model. If there is a lot of overlap in the photos, the terrain model can also be computed from the photos itself (This is actually what I currently do in my day job). All data that is required for this is freely available. You can use well traces streets in OSM for establishing the ground control points in step 1). The SRTM model required for orthorectification is available in the public domain (at least for areas south of 60° northern latitude). The main problem is that there is no complete open source software package for this job. All the components are available in various software packages, but they are not integrated: - Tie points can be created in hugin or with other matching software. With a bit of scripting, GCPs can be derived from tie points measured against OSM maps (its just coordinate transformation and lookup in the elevation model). - A complete package that takes care of most steps required for 1) and 2) is bundler, http://phototour.cs.washington.edu/bundler/ however, this is not designed to handle ground control points, so it won't give you absolute coordinates. It uses a customized version of SBA http://www.ics.forth.gr/~lourakis/sba/ for the bundle adjustment. SBA recently been extended so that it supports both tie points and ground control points. - Orthorectification can be done using open source remote sensing software packages such as http://www.ossim.org or http://www.orfeo-toolbox.org. However, these packages are mostly designed for handling commercial satellite and aerial imagery, and I'm not sure if the support a simple camera model. Then there is e-foto, which I have just downloaded as tried, but I didn't manage to do something useful with it. So the correct way to produce nice orthophotos as shown by the map providers is not that simple using open source software, and needs quite some gluing together of several packages. Hugin is currently not really suited for aligning all your images. However, the latest work in panotools (as mentioned in the reply by Lukas) might help if your area is reasonably flat. The new parameters Tx, Ty and Ts parameters in panotools should allow you to "orthorectify" your images to a plane. As these are are very new, they are not supported in hugin yet. This means that you need to use the panotools script interface from the command line directly. Maybe the following procedure might work (disclamer: I haven't tried anything of that myself!): 0. Get and compile the current trunk of libpano13 1. Load a few overlapping images captured from different viewpoints (maybe start with 3 or so) into hugin, and create a few good control points between them (make sure that they are good, to avoid confusion due to mismatched control points later on). Try to load a very well downwards looking image as first image. This image will define the plane to which the other images are warped later on. Do not optimize yet. Make sure that the field of view of the images is reasonably correct. (Computation from EXIF data is probably good for the first try). 2. Set the projection to rectilinear, and choose a wide HFOV and VFOV, such as 90 degrees or so. Press the "compute optimum size" button. 3. Export everything as panotools compatible project. The 100% bulletproof way is to go to the optimisation tab, tick the "edit script before optimisation" (or similar) checkbox, press Optimize and select the text of the checkbox and save it into a textfile named optimize.txt 4. Now you need to select which variables to optimize, using by adding them to the v line in optimize.txt. I would try optimizing roll, pitch, yaw and Tx, Ty, Ts for all but the first image. Run $ PToptimizer optimize.txt to perform the optimisation. Check the file to see some information about the errors. Here some trial and error with different parameter sets is probably needed. 5. Test remapping the images with PTmender: $ PTmendler optimize.txt 6. Combine the without any blending using PTroller $ PTroller -o output.tif remapped1.tif remapped2.tif remapped3.tif This will make the seams more visible. If that works very well, one could maybe replace the first image with a larger OSM image and use that to define the plane to which the images should be projected. Control points between the photos and the OSM map could then be used for pinning the photos to the map (as mentioned, this will only work well for flat regions!) This might work up to a certain size, and probably best for regions near the equator if the default spherical mercator image is used. It is probably better to use an OSM map that has been projected to your local UTM Zone, as it has less distortions. ciao Pablo Matt Williams wrote: > Hi guys, I've only recently discovered Hugin so I'm still getting used > to it so bear in mind that there's probably still plenty I'm missing. > > The method I've been using so far (and I've only done a few small > tests with it, nothing large scale) is based on > http://www.dojoe.net/tutorials/linear-pano/ > and is to select a few (that's only 2 or 3 so far) overlapping images > which are very nearly vertical, add them to Hugin and deselect the > 'Image Center Shift' link for the lens. I've autopano-sift'd them to > add control points. Then, I've added a png of a map image (from > openstreetmap) as the first image, set a different lens number for it > (made up a DoV of about 10 degrees) and set it as the position anchor. > Then I've manually added control points (by hand) between each of the > images and the map in order to try to coerce Hugin to align the images > to the map. > > I then enblend the remapped images together (excluding the map png) > and upload it to http://warper.geothings.net/ which is our map warper > for aligning it to the map. This allows me to slightly tweak the > rectification to make it match the map more closely. This mostly works > for small image clusters but I am ofter getting divergence from the > map at the edge of the image. > > What I would like to ask is whether anyone has any experience with > this sort of work and has some suggestions about the best way to do it > or if Hugin/Panorama Tools really isn't suitable for the job. I've > looked through a paper published on this topic at > http://www.cc.gatech.edu/~pesti/pubs/mapstitcher.pdf and it seems to > suggest the best results are achieved when doing the stitching and > ortho-rectification (and map alignment) at the same time to avoid > cumulative errors (as seen at > http://warper.geothings.net/uploads/1315/original/test3.jpg, > that main road should be almost straight). > > Thoughts/suggestions/revelations? > > Regards, > Matt Williams > http://milliams.com > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~---
