2009/9/21 Pablo d'Angelo <[email protected]>: > 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.
Yes, I've been experimenting with using bundler for analysing the camera positions but it's fairly undocumented so it'll be a while before I can get it to work for me. I'll also have a closer look at SBA. I've compiled the latest version so I'll see what it can tell me. > - 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. I'll have a look at them to see if they can be of any use. Even if they're not suitable for our purpose, I'm sure that I'll learn something :) > Then there is e-foto, which I have just downloaded as tried, but I > didn't manage to do something useful with it. Yes, I've got e-foto but I couldn't get it to do anything useful either yet. It seems it's more of a research project and as such, it's rather underdocumented (at least in English). > 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. These steps seem to work fine for a set of about 3 or 4 images. PTroller tried to create an output image which was well over 4 GB large (before I stopped it) so I just had to use enblend instead. I'll try with another set from the centre of the town where there should be more overlapping images. > 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. This is the method I had been using before, but obviously without the Tilt parameters and so it really struggled. I'll continue to play around with things since it would be nice to have something to show (even if it's only a small satellite village's worth) at the AGI GIS later this week.That is, after all, why Stratford-upon-Avon was chosen. Thanks a lot for all your suggestions. I think I'm going to have to get a working group together within OSM to try to work on these problems. This experiment with aerial photography will likely be repeated again and so I feel it's worthwhile for us to create a strong open source workflow for creating full stitched images. -- 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~---
