Christoph,
Thanks for the information. I tried out stereo and your tutorial. I
need to ask something, however. AFAICT, stereo xyz output for only the
points that you click on in the 2 images. So, after calibration, if
you click on 6 points, you get xyz coordinates for those 6 points and
no more. That is, it does not create a regular grid of xyz points to
use for DEM creation. Is this correct? Or am I missing something?
Note that I could see the xyz point output in the terminal-like
window, but could not see the rendering because I can't determine how
what to push on my Mac keyboard that it will recognize as alt-R.
Michael
On Dec 12, 2009, at 4:44 PM, [email protected] wrote:
Date: Sun, 13 Dec 2009 00:39:04 +0100
From: Christoph H?gl <[email protected]>
Subject: Re: [GRASS-user] Re: [GRASS-dev] DEM creation from stereo
pairs
To: [email protected]
Message-ID: <[email protected]>
Content-Type: Text/Plain; charset="iso-8859-1"
Am Samstag, 12. Dezember 2009 22:18:37 schrieb Hamish:
Hamish:
have a look at:
http://grass.osgeo.org/gdp/stereo-grass/
I'm pretty sure there was a FOSS conference paper on that
method a few years ago.
Michael:
Unfortunately, the requisite "stereo" package not only has
not been maintained since 1997 (according to the stereo-grass
page), but its web page has disappeared too.
the question is, how well did it work back then? working code
remains working code. :)
you might try to look for a copy of the website on archive.org,
if not maybe I or one of us has an old copy of the source
somewhere in the old dusty attic.
shrug
Hamish
Well, the package did work and sometimes still does.
it's job.
The accuracy of the process after tweaking it a bit for small
rounding mishaps
is about 12 to 14 bits (16bits data input). In comparison a hugin-
based
process achieves a little -literally- 1 bit more of accuracy at
about 5 times
the amount of time for data preparation (human) and 3-fold data
processing
time (cpu-time).
In the old times of stereo I even had to reduce resolution of the
source
images in order to get them processed with 256M of RAM (8 Mega-Pixels
(3344x2508) down to 4 MP (2364x1772) at that time)
It still provided about pixel accuracy with regards to optical
problems
(mirage/thermal inversion/turbulence of the air caused by heat/cold).
To make it more feasible:
Using a mounted camera 8 MP (which is common these days in this work
field),
provides at a field of view of 45� a angular distance of about 48
arc seconds
or about 1/75 of a degree which gives a accuracy of about 23cm at a
distance
of 1000 meters. The atmospheric effect at that distance is way
beyond (~ 3
meters)
If you are after taking photos in less ambitious way, let's say
shooting an
excavation from 100m or less, the accuracy is -> 2.3cm at best,
obviously
better near the center of field (less lens distortion, ...) and
nearer to the
lens (less atmospheric (d)ef(f)ects).
Even if we take a sefety measure of factor 5 for each photo taken
using a
shaky tripod or even factor 10 from a kite mounted camera and
multiply all
worse effects instead of flattening out, the accuracy still exceeds
most needs
at archeological sites (2.54cm = 1 inch) at distances of up to 25 m
by a
factor of 8.
The worst case i had with stereo was a misplacement by 1.5m at 100m
distance
using scans of ballon-mounted photograph from the late 30ies
combined with
a 2003 photo taken using 4MP camera. (BTW, the 4MP was the culprit
in the end)
One of the miracles using stereo was the ability to revisit a place
in the
desert by triangulation using stereo after 8 years with 30cm
accuracy and
pretty unsharp joshua-trees in the background (at distances of ~15m
and ~25m
unsharp, 6 team photos taken in front of a car, taking the rim as
rule using a
4MP camera). GPS Data was misleading by 4-8 meters.
The main reason for using stereo is it's ability to combine
different sorts of
source materials (plates/film/digital imagery) in pretty short time.
(I use it
still as stated above for small projects, where only a few points in
3d-space
need to be 'surveyed')
As stereo takes more than 2 pictures it is even more powerful than
most
standard off-the-shelf commercial solutions.
The main reasons against it's use is the lack of automation in the
process,
the lack of dedicated support (I'm not able to provide it, though
stereo would
really deserve it) as well as the lack of camera/lens adjustment
combined with
a really awful codebase.
Hope that helps a bit,
Christoph
_______________________________________________
grass-user mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-user
