Aerial Photography Stitching
Matt Williams
to it so bear in mind that there's probably still plenty I'm missing.
I'm a mapper for OpenStreetMap (http://openstreetmap.org), a project
to create a free map of the world. Recently someone sponsored a round
of amateur aerial photography of the area around the town of Stratford-
upon-Avon in the UK. We now have the full set of aerial imagery
(around 900 photos) of the whole town from various directions and at
various angles to the vertical. You can see a summary of the data at
http://milliams.com/verticalitymetre/stats.php and
http://milliams.com/verticalitymetre/map.html (where a low number
score is more vertical).
Now, we've got to the stage where we would like to be able to rectify
this imagery to the map and stitch all this imagery together in a
mostly seamless way. Perhaps Hugin/Panorama Tools isn't really what I
should be using for this but it's so close to doing what we need, I'd
be surprised if it couldn't be coerced into shape.
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
Lukáš Jirkovský
2009/9/21 Matt Williams <li...@milliams.com>:
Tz and Ts) but doesn't use them yet.
I'd try to load map into hugin and manually add control points to
photos and corresponding parts of map. Then optimize with map set as
anchor image. This would hopefully transform images to fit map
directly in hugin. And for stitching I'de disable the map so it
doesn't blend with photos by coincidence.
Anyway, interesting project.
regards,
Lukas
Matt Williams
> First, there are some new tilt options to the panorama tools (Tx, Ty,
> Tz and Ts) but doesn't use them yet.
I've had a look through the archives and I see that the options you
mention could indeed be very useful. What version of Hugin are these
likely to turn up in? I don't mind building from source but I'd like
to know which branch to get. Or should I just grab trunk?
> I'd try to load map into hugin and manually add control points to
> photos and corresponding parts of map. Then optimize with map set as
> anchor image. This would hopefully transform images to fit map
> directly in hugin. And for stitching I'de disable the map so it
> doesn't blend with photos by coincidence.
Yes, that's what I've been doing so far but I'm unable to stitch
together more than about 3 images before it significantly deviates (as
in ~20 ground distance) from the map. The tilt options should help
with this, even if they don't allow me to stitch any more together at
once but only allow the images to be more accurate. Really for our
purposes, accurately conforming to the ground truth is more important
than seamless blending or colour balance (though they would help).
--
Matt Williams
http://milliams.com
Pablo d'Angelo
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.
>
Pablo d'Angelo
> 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.).
Sorry, this was confusing. This is a better explanation: Tie point are
measured between the images, Ground Control points are measured between
the image and some reference data (maps, gps traces, digital elevation
models, geodetic gps measurements etc.).
ciao
Pablo
Oskar Sander
If you experiment on this further, it would be really sweet if you did a tutorial writeup here even if it doesn't work out perfect right now.
0. Get and compile the current trunk of libpano13
If you so happens to build panotools on windows, pls drop me a mail. (and I'll give this a try too)
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.
I would think you should optimize for x(d), y(e), Tx, Ty, Tz and Ts. Yaw, pitch and roll would put the result off, as it is done though panorama center and not camera center.
Cheers
--
/O
Matt Williams
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).
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
> Hi Matt,
>
> If you experiment on this further, it would be really sweet if you did a
> tutorial writeup here even if it doesn't work out perfect right now.
I absolutely will. This won't be the last time that OSM hire a plane
for some aerial photography and so it's important that we find a
decent way of doing it.
The final images (like the source images) will be creative-commons
licensed and will be available to the public for tracing (or whatever)
so I'll be sure to update this list when I've got something
good-looking.
>> 0. Get and compile the current trunk of libpano13
>
> If you so happens to build panotools on windows, pls drop me a mail. (and
> I'll give this a try too)
Sorry, I'm on Linux. I found Panotools really quick and easy to build though.
>> 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.
>
> I would think you should optimize for x(d), y(e), Tx, Ty, Tz and Ts. Yaw,
> pitch and roll would put the result off, as it is done though panorama
> center and not camera center.
Ok, I'll have a try with those parameters to see if it gives any
better results. I'm still getting used to the notations and parameters
used by Panotools so I'm pretty much going by what people suggest and
trial and error at the moment.
Stefan de Konink
Hash: SHA512
Matt Williams schreef:
> 2009/9/22 Oskar Sander <oskar....@gmail.com>:
>> Hi Matt,
>>
>> If you experiment on this further, it would be really sweet if you did a
>> tutorial writeup here even if it doesn't work out perfect right now.
>
> I absolutely will. This won't be the last time that OSM hire a plane
> for some aerial photography and so it's important that we find a
> decent way of doing it.
Thats why we got money for http://www.openstreetphoto.org/ see our blog:
http://blog.opengeo.nl/ We have two aircrafts and get two more, this
time 3 meter wide electro-gliders :)
Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREKAAYFAkq42eAACgkQYH1+F2Rqwn1VaQCeNMnl08L9SyZTzM8zIkexmDCt
GaoAoIFiKZtVOpH4N7jW7Nl/eydxBoIw
=9oji
-----END PGP SIGNATURE-----
Matt Williams
> Matt Williams schreef:
>> 2009/9/22 Oskar Sander <oskar....@gmail.com>:
>>> Hi Matt,
>>>
>>> If you experiment on this further, it would be really sweet if you did a
>>> tutorial writeup here even if it doesn't work out perfect right now.
>>
>> I absolutely will. This won't be the last time that OSM hire a plane
>> for some aerial photography and so it's important that we find a
>> decent way of doing it.
>
> Thats why we got money for http://www.openstreetphoto.org/ see our blog:
> http://blog.opengeo.nl/ We have two aircrafts and get two more, this
> time 3 meter wide electro-gliders :)
Hey Stefan. I was wondering when you might turn up. I guessed you
don't read tal...@osm.org but I knew you were working on stuff in
this area. From what I could tell, you haven't made much progress with
processing the images yet (although I do like the quadcopter thing
:D). If I'm mistaken or if you could be of help with the Stratford
Imagery it would be much appreciated. I haven't been able to find any
mailing list discussions of your work.
In the mean time, I've found that some people have started a project
based on Orfeo-toolbox for simplifying the workflow and it sounds like
it could be useful for our purpose, they even mention OpenStreetMap
(http://wiki.orfeo-toolbox.org/index.php/Monteverdi).
Perhaps we'd do well to take this discussion to an OSM list of some
kind (maybe 'photos@' or 'talk@')?
Stefan de Konink
Hash: SHA512
Matt Williams schreef:
> Hey Stefan. I was wondering when you might turn up.
I have posted bounties on this list for increasing documentation and for
features ;) So I turned up well before you ;)
> I guessed you
> don't read tal...@osm.org but I knew you were working on stuff in
> this area. From what I could tell, you haven't made much progress with
> processing the images yet (although I do like the quadcopter thing
> :D). If I'm mistaken or if you could be of help with the Stratford
> Imagery it would be much appreciated. I haven't been able to find any
> mailing list discussions of your work.
We did; we have a rectifying program, and like I posted before I was
pointed myself to efoto. From there on we can use qgis and mapserver for
final positioning. Come and idle in #osp on oftc ;)
> In the mean time, I've found that some people have started a project
> based on Orfeo-toolbox for simplifying the workflow and it sounds like
> it could be useful for our purpose, they even mention OpenStreetMap
> (http://wiki.orfeo-toolbox.org/index.php/Monteverdi).
I guess we should all focus on implementations that already exist?
> Perhaps we'd do well to take this discussion to an OSM list of some
> kind (maybe 'photos@' or 'talk@')?
Also a possibility.
Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREKAAYFAkq5A0IACgkQYH1+F2Rqwn2APwCfczUDKoqrodPiNVdbp/H8kYar
mogAn0hnBJuWS3MZamAAXdPzFFlIrnpr
=ZbO+
-----END PGP SIGNATURE-----
Pablo d'Angelo
> This is the method I had been using before, but obviously without the
> Tilt parameters and so it really struggled.
Actually, I played around a little, and I wasn't satisfied with the tilt
parameters, so changed libpano to allow estimate the X,Y and Z camera
position (assuming a planar earth). I still need to do some final
testing, but so far it doesn't look too bad.
> 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.
Please keep me updated. Where do you discuss these issues?
ciao
Pablo
Pablo d'Angelo
> 2009/9/22 Oskar Sander <oskar....@gmail.com>:
>> Hi Matt,
>>
>> If you experiment on this further, it would be really sweet if you did a
>> tutorial writeup here even if it doesn't work out perfect right now.
>
> I absolutely will. This won't be the last time that OSM hire a plane
> for some aerial photography and so it's important that we find a
> decent way of doing it.
I have played a little with the images, and from my perspective, it
would be more usable, if the camera with a wide angle lens (maybe 28 mm
instead of 50 mm) would be used especially for the nadir shots. Flying
at a higher altitude will probably also help.
They probably still have enough detail for mapping (you probably do not
need 5 cm ground resolution or so, 10 or 20 cm are probably enough to
recognize most details required for mapping.
At work, we have a full frame camera system ( 3xCanon EOS-1d) with 50 mm
lenses. Flying that at 1000m gives reasonable detail when looking
straight down and the imaged area is much larger than with your example
images, making them easier to handle.
ciao
Pablo
Pablo d'Angelo
> We did; we have a rectifying program, and like I posted before I was
> pointed myself to efoto. From there on we can use qgis and mapserver for
> final positioning. Come and idle in #osp on oftc ;)
Do you have a procedure that works nicely for the large amount of image?
I couldn't find anything on http://www.openstreetphoto.org ?
ciao
Pablo
Matt Williams
> Hi Matt,
>
>> This is the method I had been using before, but obviously without the
>> Tilt parameters and so it really struggled.
>
> Actually, I played around a little, and I wasn't satisfied with the tilt
> parameters, so changed libpano to allow estimate the X,Y and Z camera
> position (assuming a planar earth). I still need to do some final
> testing, but so far it doesn't look too bad.
I see you've checked some of these changes into SVN, I've uncommented
the '#define MOSAIC_XYZ 1' line in adjust.c. Is there anything I need
to do elsewhere to allow it estimate these variables?
>> 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.
>
> Please keep me updated. Where do you discuss these issues?
Well, I only got involved in this a few days ago but Stefan de Konink
has been looking at this for a while now. As I understand it, most
discussion has gone on in the Dutch language list so far.
Matt Williams
Ok. That's definitely something worth considering for the future. For
the shots you've seen, the camera was provided by whoever in the area
had a camera and free time for when the plane was booked. It's
possible we could obtain a higher quality camera as a community. I
guess Stefan won't want to spend his grant money on a camera that is
too heavy for a Quadcopter :)
Pablo d'Angelo
> 2009/9/22 Pablo d'Angelo <pablo....@web.de>:
>> Hi Matt,
>>
>>> This is the method I had been using before, but obviously without the
>>> Tilt parameters and so it really struggled.
>> Actually, I played around a little, and I wasn't satisfied with the tilt
>> parameters, so changed libpano to allow estimate the X,Y and Z camera
>> position (assuming a planar earth). I still need to do some final
>> testing, but so far it doesn't look too bad.
>
> I see you've checked some of these changes into SVN, I've uncommented
> the '#define MOSAIC_XYZ 1' line in adjust.c. Is there anything I need
> to do elsewhere to allow it estimate these variables?
No. With these you could just try to optimize y,p,r,Tx,Ty,Tz for all
images except the first one.
ciao
Pablo
Pablo d'Angelo
There is a bug in panotools. Sometimes it does not optimize parameters
if they are exactly set to 0. This seems to affect the Tx, Ty and Tz
parameters as well (a,b,c parameters are the other parameter that suffer
from this).
So simply add Tx0.1 Ty0.1 Tz0.1 to "i" lines, except for the first one.
Note: the names of the Tx, Ty, Tz parameters are only valid with the
current svn and the MOSAIC_XYZ define in adjust.c. They will be
available under another name in the future (probably just X Y Z).
Here is the result of merging images 539-549 from
http://vps-1005786-1584.united-hoster.de/tmp/539-549.jpg
It is not referenced to an OSM map (too late in the evening...), but the
result looks very promising. It also shows that the sideward views are
probably not that helpful for mapping, at least when reprojecting them.
Quick procedure:
1. panomatic -o 539-549.pto *.jpg
2. hugin 539-549.pto
- set focal length to 50mm (~ HFOV 26°)
- open fast preview
- set projection to rectilinear,
- select hfov and vfov ~ 100
- show only the first image.
- use the drag tool to move the first image so that it roughly
looking like a nadir image
- select all images again
- Go to the optimizer tab, select (optimize y,p,r)
- tick "edit script"
- copy script into a text file 539.549.txt
- Edit script, add
Tx0.1 Ty0.1 Tz0.1 to "i" lines, except for the first one.
- modify the v lines to include Tx# Ty# Tz# (where # is the image
number)
- run PToptimizer 539-549.txt
- run PTmender -o 539-549 539-549.txt
- run PTroller -o 539-549.tif 539-5490*.tif
- crop 539-549.tif in your favorite image editor.
ciao
Pablo
Stefan de Konink
Hash: SHA512
Pablo d'Angelo schreef:
> Do you have a procedure that works nicely for the large amount of image?
Next to just adding them to Hugin and per photo stitching we don't have it.
But I saw your last email and I wonder:
How did you solve the altitude difference? Because we have many
problems with that. If in one flight different altitudes were flown
hugin really can't stitch it.
Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREKAAYFAkq5UtYACgkQYH1+F2Rqwn2qmQCfTiYr4LxyjFtMO+HVa1em2Jw9
Lw0AnjryTx1OfjSylBBltgHSAh68yvIW
=VKWd
-----END PGP SIGNATURE-----
Dale Beams
Dale
> Date: Wed, 23 Sep 2009 00:42:30 +0200
> From: ste...@konink.de
> To: hugi...@googlegroups.com
> Subject: [hugin-ptx] Re: Aerial Photography Stitching
Oskar Sander
I just have to ask to clarify in my mind the geometry. Have I understood correctly that:
* The parameters Tx,Ty,Tz (soon X,Y,Z) are now camera shift (Not attitude aka "tilt")
* The y,p,r parameters are now changed from the "old" model so they apply to the camera center (=X,Y,Z)
Right?
Is it possible to view the source images to this example?
About altitude, in the old/current hugin/panolib model i have sometimes got ok result where individual FOV(v) for the lenses/images represent the altitude indirectly.
Cheers
/O
Matt Williams
> Is it possible to view the source images to this example?
Go to http://78.46.66.234/jpeg1600/ and scroll down to image
DSC00539.jpg Pablo used DSC00539.jpg through to DSC00549.jpg to create
the image above. There are higher resolution versions at
http://78.46.66.234/jpeghigh/.
Stefan de Konink
Hash: SHA512
Dale Beams schreef:
> There is software out there for model RC planes that will allow you to
> use an altimeter and get a constant height with a gps combo It'll fly a
> grid pattern as well.
Yeah right, does that 'software out there' also stitch photo's taken
from different altitudes?
Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREKAAYFAkq6HV8ACgkQYH1+F2Rqwn0/8gCfcv6MpQHZ65bSMypEsBLiKUGY
fjcAmQGe6HA6zZXgqIsnFfMdHpaGoeHY
=AxDZ
-----END PGP SIGNATURE-----
Oskar Sander
I think the result looks really nice Pablo!
It would be really interesting if the result continue to come out as nice if some more pic in the flightpath (= even more x & y camera shift) are included in the project like with adding these pictures.
DSC00554-555
558-559-560
562-563-564
Cheers
/O
Dale Beams
Mountains could be a challenge, if you were taking a photo parallel to the ground, ie, up the side of the mountain, it's still "gadging" your height from the ground to the plane regardless of the plane's orientation, and/or keeping the plane in a flat plane as it climbes up the mountian.
The free and gnu software I mentioned has quite a bit of functionality.
Dale
> Date: Wed, 23 Sep 2009 15:06:39 +0200
> From: ste...@konink.de
> To: hugi...@googlegroups.com
> Subject: [hugin-ptx] Re: Aerial Photography Stitching
>
>
Stefan de Konink
Hash: SHA512
Dale Beams schreef:
> One doesn't need to take at different heights if your "locking" in your
> height from ground to plane. I live in the "Plains" and everything is flat.
Likewise here. But still if one blow of wind can take a quad copter
about 2 meters down. That *does* matter, optically.
Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREKAAYFAkq6QP0ACgkQYH1+F2Rqwn2UhACbBiLfIQK8Oa37mz5xZOg5GSjt
2VYAn0HHSbWKUoMrUZ94ZclhBYyr4JRk
=ykDT
-----END PGP SIGNATURE-----
Bruno Postle
>
>Quick procedure:
>
>1. panomatic -o 539-549.pto *.jpg
>2. hugin 539-549.pto
> - set focal length to 50mm (~ HFOV 26°)
> - open fast preview
> - set projection to rectilinear,
> - select hfov and vfov ~ 100
> - show only the first image.
> - use the drag tool to move the first image so that it roughly
>looking like a nadir image
> - select all images again
> - Go to the optimizer tab, select (optimize y,p,r)
> - tick "edit script"
> - copy script into a text file 539.549.txt
> - Edit script, add
> Tx0.1 Ty0.1 Tz0.1 to "i" lines, except for the first one.
> - modify the v lines to include Tx# Ty# Tz# (where # is the image
> number)
>
> - run PToptimizer 539-549.txt
> - run PTmender -o 539-549 539-549.txt
> - run PTroller -o 539-549.tif 539-5490*.tif
> - crop 539-549.tif in your favorite image editor.
Works for me, I also found that I can successfully optimise lens
parameters:
http://www.flickr.com/photos/36383814@N00/3947727801/
..so when can we have this in Hugin? ;-)
--
Bruno
dmg
did you try optimizing using the tilt model? Tx, Ty and Ts (try those
before you try Tz).
I'll be curious to see what happens.
Could you post the script so I can try it? Thanks!
--dmg
--dmg
---
Daniel M. German
http://turingmachine.org
Pablo d'Angelo
Bruno wrote:
> Works for me, I also found that I can successfully optimise lens
> parameters:
>
> http://www.flickr.com/photos/36383814@N00/3947727801/
>
> ..so when can we have this in Hugin? ;-)
It doesn't make sense to add these the the trunk, as it would complicate
the merging of layout. I'll looking into adding them to the layout branch.
Btw is there a list of issues in the tracker (or somewhere else) for the
problems in the layout branch?
ciao
Pablo
Bruno Postle
>
>did you try optimizing using the tilt model? Tx, Ty and Ts (try those
>before you try Tz).
>I'll be curious to see what happens.
Sorry, I only tried Pablo's modified version.
>Could you post the script so I can try it? Thanks!
I think I put all the photos and the script here:
http://bugbear.postle.net/~bruno/misc/DSC00169-DSC00184.zip
This is quite an extreme example, I deliberately took photos from
lots of different angles and distances.
>> Works for me, I also found that I can successfully optimise lens
>> parameters:
>> http://www.flickr.com/photos/36383814@N00/3947727801/
--
Bruno
Pablo d'Angelo
Oskar Sander schrieb:
> Thanks, I see. So the method was to take one shot as straight down as
> possible and then to take consecutive shots panning out towards the
> horizon perpendicular to the flightpath, and then repeat that procedure
> from the downward view, right?
Looks like it, but it doesn't seem to be the very best option. I'd liked
to have more nadir shots and with a wide angle lens.
So for your diving activities, better look straight down, and swim as
high as possible over the area of interest (which is probably hard,
given visibility constraints).
> I think the result looks really nice Pablo!
>
> It would be really interesting if the result continue to come out as
> nice if some more pic in the flightpath (= even more x & y camera shift)
> are included in the project like with adding these pictures.
> DSC00554-555
> 558-559-560
> 562-563-564
I have done some experiments and added support for XYZ into the
gsoc2008_layout branch (not commited yet, as the variable names in
libpano13 will change soon, I hope).
Here are the results of using the above images and aligning it onto an
OSM map image. It took some efforts to selecting the right control
points between the map and the images. I also used many straight line
control points, as it is hard to measure the position of an single point
precisely.
Results:
Mosaic (4800x6400 pixels):
http://vps-1005786-1584.united-hoster.de/tmp/osm_mosaic/with_manual_control_merged.jpg
Mosaic blended with map (4800x6400 pixels):
http://vps-1005786-1584.united-hoster.de/tmp/osm_mosaic/with_manual_control_merged_overlay.jpg
source data with hugin projects and control points:
http://vps-1005786-1584.united-hoster.de/tmp/osm_mosaic/osm_aerial_mosaic.zip
This is probably a good test case to compare the XYZ model with the tilt
model.
ciao
Pablo
Yuval Levy
to push the envelope and see if it can be used for a large linear
panorama riddled with obstacles, parallax, and all funny things to deal
with.
The good news is that TiX, TiY, TiZ is *very promising*.
The bad news is that the process is extremely dependent on having all
CPs on a single plane - just the relief on the brick walls I shot seems
to be enough to generate significant error. The best I got it down was
around RMS 6, although at one attempt I even got to RMS 4.
Bruno Postle wrote:
> On Wed 23-Sep-2009 at 00:37 +0200, Pablo d'Angelo wrote:
>> Quick procedure:
>>
>> 1. panomatic -o 539-549.pto *.jpg
lots of CPs to prune after this stage. I guess I am better off with
manually setting them. Do I understand correctly that if I use a
calibrated lens and optimize only for y,p,r,TiX,TiY,TiZ I need six CPs
per image pair?
>> 2. hugin 539-549.pto
>> - set focal length to 50mm (~ HFOV 26°)
I guess this is specific to the 539-549 project? I left the focal length
from EXIF.
>> - open fast preview
>> - set projection to rectilinear,
>> - select hfov and vfov ~ 100
>> - show only the first image.
>> - use the drag tool to move the first image so that it roughly
>> looking like a nadir image
I moved the middle image in my sequence to be the first image on the
list; and then I moved it down to the nadir by editing the pitch value
in the Images tab.
When I was using rectilinear projection in the rest of the process, it
would only render a part of the image. I ended up setting projection to
equirect HFOV360 VFOV180.
>> - select all images again
>> - Go to the optimizer tab, select (optimize y,p,r)
>> - tick "edit script"
>> - copy script into a text file 539.549.txt
>> - Edit script, add
>> Tx0.1 Ty0.1 Tz0.1 to "i" lines, except for the first one.
>> - modify the v lines to include Tx# Ty# Tz# (where # is the image
>> number)
>> - run PToptimizer 539-549.txt
>> - run PTmender -o 539-549 539-549.txt
>> - run PTroller -o 539-549.tif 539-5490*.tif
done everything as above. then I loaded the resuting equirect in Hugin.
The image is on the nadir. I reprojected it to rectilinear and set the
appropriate view. Because it is quite long I get some distorsion at the
extremes (and the rectilinear needs to be projected on 150°).
maybe I should have set a longer focal length / smaller HFOV at step 2
instead of using the EXIF, to "simulate" more distance from the sphere
and thus get a longer panorama within a reasonable HFOV for the
rectilinear projection?
> Works for me, I also found that I can successfully optimise lens
> parameters:
I also tried with optimizing lens parameters. a/b/c work. I did not try
to optimize FOV (v?). When I tried to optimize d and e I got the btter
RMS but the images where very much shifted.
> ..so when can we have this in Hugin? ;-)
I guess the answer is: when the layout branch is merged to trunk. what
is its status?
Yuv
Pablo d'Angelo
>> lenses. Flying that at 1000m gives reasonable detail when looking
>> straight down and the imaged area is much larger than with your example
>> images, making them easier to handle.
>
> Ok. That's definitely something worth considering for the future. For
> the shots you've seen, the camera was provided by whoever in the area
> had a camera and free time for when the plane was booked. It's
> possible we could obtain a higher quality camera as a community.
Actually, the camera was ok, but maybe just use a wider angle lens and
do mostly downward looking shots, and fly higher, if possible.
Flying higher will also make the mosaicing and interpretation of the
pictures easier.
Btw. real aerial cameras (for example. UltraCam
http://www.microsoft.com/ultracam/default.mspx ), as used by the mapping
agencies, are probably 50 to 100 times as expensive as a Canon EOS 1D
something.
ciao
Pablo