Re: [GRASS-user] DEM creation from stereo pairs
Michael, don't know if it matches your needs as it is not an automatic process but I remember a long time ago I used e-foto, formerly only available on windows. It was a very rough photogrammetry station which allowed to digitize contour lines on the basis of stereo couples. Nowadays I see the project is still alive and was ported to Qt : http://www.efoto.eng.uerj.br Hope it can help, Bye, Vincent Le vendredi 11 décembre 2009 à 21:02 -0700, Michael Barton a écrit : Can anyone recommend open source tools for creating a DEM from stereo image pairs? Thanks Michael Barton C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Phone: 480-965-6262 Fax: 480-965-7671 www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.rescale categories definition
Dear GRASS Users and Developers, I'm having some problem in understanding the categories resulting from r.rescale With: r.rescale in=elevation.dem from=1200,1500 to=1,2 out=elev.resc I have this result: 1 1200 thru 1349 2 1350 thru 1500 Two categories with a range of 150 meters each. But with a new three categories subdivision: r.rescale in=elevation.dem from=1200,1500 to=1,3 out=elev.resc the result is: 11200 thru 1274 21275 thru 1424 31425 thru 1500 The first and last categories have a range of 75 meters and the second one of 150 meters. Similar result with a four categories subdivision: r.rescale in=elevation.dem from=1200,1500 to=1,4 out=elev.resc 11200 thru 1250 21251 thru 1350 31351 thru 1450 41451 thru 1500 Categories 1 and 4 have a range of 50 meters, 2 and 3 a range of 100 meters. It seems that the first and last categories have the half range of all the others ones. Is this correct? Shouldn't the range be the same for all categories? (same results with GRASS6.4, GRASS6.3 and GRASS6.2). Many thanks in advance A. Clerici Parma University Italy ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.rescale categories definition
On Saturday 12 December 2009 11:03:35 Aldo Clerici wrote: Dear GRASS Users and Developers, I'm having some problem in understanding the categories resulting from r.rescale With: r.rescale in=elevation.dem from=1200,1500 to=1,2 out=elev.resc I have this result: 1 1200 thru 1349 2 1350 thru 1500 Two categories with a range of 150 meters each. But with a new three categories subdivision: r.rescale in=elevation.dem from=1200,1500 to=1,3 out=elev.resc the result is: 11200 thru 1274 21275 thru 1424 31425 thru 1500 The first and last categories have a range of 75 meters and the second one of 150 meters. Similar result with a four categories subdivision: r.rescale in=elevation.dem from=1200,1500 to=1,4 out=elev.resc 11200 thru 1250 21251 thru 1350 31351 thru 1450 41451 thru 1500 Categories 1 and 4 have a range of 50 meters, 2 and 3 a range of 100 meters. It seems that the first and last categories have the half range of all the others ones. Is this correct? Shouldn't the range be the same for all categories? (same results with GRASS6.4, GRASS6.3 and GRASS6.2). Many thanks in advance A. Clerici Parma University Italy Hi, I have not used r.rescale (perhaps it uses some form of ratio on the amount of points in given categories it assigns, hence the middle categories being larger ranges). I think r.reclass would be a better option so you can classify exactly what the categories would be. John ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
R: [GRASS-user] r.rescale categories definition
John, tanks for your quick answer. A correct reclassification can be easily obtained with r.reclass or r.mapcalc, but I would like to know if the behaviour of r.rescale is correct and in this case what's the way it uses to define categories (just to explain it to students working with GRASS). Thanks again. A. Clerici -Messaggio originale- Da: grass-user-boun...@lists.osgeo.org [mailto:grass-user-boun...@lists.osgeo.org] Per conto di John Tate Inviato: sabato 12 dicembre 2009 12.20 A: grass-user@lists.osgeo.org Oggetto: Re: [GRASS-user] r.rescale categories definition On Saturday 12 December 2009 11:03:35 Aldo Clerici wrote: Dear GRASS Users and Developers, I'm having some problem in understanding the categories resulting from r.rescale With: r.rescale in=elevation.dem from=1200,1500 to=1,2 out=elev.resc I have this result: 1 1200 thru 1349 2 1350 thru 1500 Two categories with a range of 150 meters each. But with a new three categories subdivision: r.rescale in=elevation.dem from=1200,1500 to=1,3 out=elev.resc the result is: 11200 thru 1274 21275 thru 1424 31425 thru 1500 The first and last categories have a range of 75 meters and the second one of 150 meters. Similar result with a four categories subdivision: r.rescale in=elevation.dem from=1200,1500 to=1,4 out=elev.resc 11200 thru 1250 21251 thru 1350 31351 thru 1450 41451 thru 1500 Categories 1 and 4 have a range of 50 meters, 2 and 3 a range of 100 meters. It seems that the first and last categories have the half range of all the others ones. Is this correct? Shouldn't the range be the same for all categories? (same results with GRASS6.4, GRASS6.3 and GRASS6.2). Many thanks in advance A. Clerici Parma University Italy Hi, I have not used r.rescale (perhaps it uses some form of ratio on the amount of points in given categories it assigns, hence the middle categories being larger ranges). I think r.reclass would be a better option so you can classify exactly what the categories would be. John ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] DEM creation from stereo pairs
Thanks. I'm looking into this. To run on Mac and Linux, one needs to compile this from within QT. I haven't done that and don't know what is required. Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Phone: 480-965-6262 Fax: 480-965-7671 www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Dec 12, 2009, at 2:17 AM, Vincent Bain wrote: Michael, don't know if it matches your needs as it is not an automatic process but I remember a long time ago I used e-foto, formerly only available on windows. It was a very rough photogrammetry station which allowed to digitize contour lines on the basis of stereo couples. Nowadays I see the project is still alive and was ported to Qt : http://www.efoto.eng.uerj.br Hope it can help, Bye, Vincent Le vendredi 11 décembre 2009 à 21:02 -0700, Michael Barton a écrit : Can anyone recommend open source tools for creating a DEM from stereo image pairs? Thanks Michael Barton C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Phone: 480-965-6262 Fax: 480-965-7671 www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: Hydroligics in grass
I start with, which method is better depends in part on your needs and your data. That said, we've done a lot of testing in my lab of the ability of these (and other modules like r.flow) to simulate overland flow. We've had the best results with r.watershed with the new multi-flow direction (MFD) algorithm implemented in GRASS 6.5 and 7. Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Phone: 480-965-6262 Fax: 480-965-7671 www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Dec 12, 2009, at 4:13 AM, grass-user-requ...@lists.osgeo.org wrote: Date: Fri, 11 Dec 2009 21:05:58 +0100 From: Joop Goedbloed jlgoedbl...@hetnet.nl Subject: [GRASS-user] Re: Hydroligics in grass Cc: grass-user@lists.osgeo.org Message-ID: 4b22a626.4000...@hetnet.nl Content-Type: text/plain; charset=iso-8859-1 Op 11-12-09 20:44, Joop Goedbloed schreef: Hi Users on the list To trace back the overland flood mechanism in (sub)urban area I've done some experiments in grass. (Sub)urban areas has in general a sewer-system (combined or storm). One of the design-parameters of a sewer is the maximal capacity of rainfall, in most cases e sewer is design to carry off about 20mm/h rain. In case of very heavy storm about 60 mm/h the sewer becoms full and an overland flood mechanism come into being. I've a 5x5 meter grid DEM of the area. In grass there are several modules to simulate overland flood. * r. terraflow * r.watershed * r.topmodel * r.topidx ... What is the most useful module(s) in grass to simulate overland flood mechanism? First I used the r.terraflow module the resulting accumulation map is here: Terraflow accumulation map ftp://192.168.2.107/houtblerick/teracc.png Using the r.watershed module resulting streammap is here: Watershed stream map ftp://192.168.2.107/houtblerick/wsstream.png In both maps the red boxes are the complaints of water flood A foto of the real situation is here Foto ftp://192.168.2.107/houtblericj/Holleweg.jpg For the puctures try ftp://80.61.251.86/Houtblerick/ there are the tree pictures. Thanks Joop Goedbloed -- next part -- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/grass-user/attachments/20091211/2e668bd0/attachment-0001.html ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: Hydroligics in grass
On Sat, 12 Dec 2009, Michael Barton wrote: That said, we've done a lot of testing in my lab of the ability of these (and other modules like r.flow) to simulate overland flow. We've had the best results with r.watershed with the new multi-flow direction (MFD) algorithm implemented in GRASS 6.5 and 7. Michael, I saw a reference to jgrass in an earlier thread. I've not yet looked closely at it but it apparently has modules lacking in GRASS for precipitation-runoff calculations. Have you or your students looked at jgrass? Ideally, it would be nice to have all the additional capabilities of jgrass incorporated into (C)GRASS. Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.rescale categories definition
Aldo Clerici wrote:
Dear GRASS Users and Developers,
I'm having some problem in understanding the categories resulting from
r.rescale
With:
r.rescale in=elevation.dem from=1200,1500 to=1,2 out=elev.resc
I have this result:
1 1200 thru 1349
2 1350 thru 1500
Two categories with a range of 150 meters each.
But with a new three categories subdivision:
r.rescale in=elevation.dem from=1200,1500 to=1,3 out=elev.resc
the result is:
11200 thru 1274
21275 thru 1424
31425 thru 1500
The first and last categories have a range of 75 meters and the second one
of 150 meters.
Similar result with a four categories subdivision:
r.rescale in=elevation.dem from=1200,1500 to=1,4 out=elev.resc
11200 thru 1250
21251 thru 1350
31351 thru 1450
41451 thru 1500
Categories 1 and 4 have a range of 50 meters, 2 and 3 a range of 100 meters.
It seems that the first and last categories have the half range of all the
others ones. Is this correct? Shouldn't the range be the same for all
categories?
This is a result of r.rescale rounding rather than truncating, so the
minimum and maximum input values are the midpoints of the first and
last intervals:
old_delta = old_max - old_min;
new_delta = new_max - new_min;
divisor = (float)new_delta / (float)old_delta;
...
for (cat = old_min; cat = old_max; cat++) {
value = (int)(divisor * (cat - old_min) + new_min + .5);
You can get balanced intervals with:
#!/bin/sh
inmap=$1
outmap=$2
to_min=$3
to_max=$4
eval `r.info -r $inmap`
awk -vold_min=$min -vold_max=$max -vnew_min=$to_min -vnew_max=$to_max '
BEGIN {
new_delta = new_max - new_min + 1
old_delta = old_max - old_min + 1
for (i = 0; i new_delta; i++) {
lo = old_min + i * old_delta / new_delta
hi = old_min + (i+1) * old_delta / new_delta - 1
new = new_min + i
printf(%d thru %d = %d %d\n, lo, hi, new, lo)
}
}' | r.reclass in=$inmap out=$outmap
E.g.:
./rescale.sh elevation.dem elev.resc 1 4
--
Glynn Clements gl...@gclements.plus.com
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] DEM creation from stereo pairs
Compiling from Qt seems quite easy on Linux : after unzipping the source code archive, from within each module directory, you just have to run qmake-qt4 to compile .pro files, then make install in order to create (local) executables. I tried with 'exterior' module, it works fine. Vincent. Le samedi 12 décembre 2009 à 08:31 -0700, Michael Barton a écrit : Thanks. I'm looking into this. To run on Mac and Linux, one needs to compile this from within QT. I haven't done that and don't know what is required. Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Phone: 480-965-6262 Fax: 480-965-7671 www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Dec 12, 2009, at 2:17 AM, Vincent Bain wrote: Michael, don't know if it matches your needs as it is not an automatic process but I remember a long time ago I used e-foto, formerly only available on windows. It was a very rough photogrammetry station which allowed to digitize contour lines on the basis of stereo couples. Nowadays I see the project is still alive and was ported to Qt : http://www.efoto.eng.uerj.br Hope it can help, Bye, Vincent Le vendredi 11 décembre 2009 à 21:02 -0700, Michael Barton a écrit : Can anyone recommend open source tools for creating a DEM from stereo image pairs? Thanks Michael Barton C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Phone: 480-965-6262 Fax: 480-965-7671 www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] DEM creation from stereo pairs
and don't know what is required. Oh, on Debian-based distros, qmake-qt4 should be in the libqt4-dev package Vincent. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] DEM creation from stereo pairs
Thanks for the advice. We'll give this a try. Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Phone: 480-965-6262 Fax: 480-965-7671 www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Dec 12, 2009, at 10:13 AM, Vincent Bain wrote: and don't know what is required. Oh, on Debian-based distros, qmake-qt4 should be in the libqt4-dev package Vincent. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: Hydroligics in grass
Yes. We've looked at jgrass. It was rather quiescent when we started out work, but has been re-energized recently. I agree that it would be nice to have the Java-based Horton machine modules available for the GRASS community. However, as is the case with all truly open source projects, contribution to GRASS is voluntary. Moreover, all are free to use GRASS code. But as long as they comply with the requirements of the GPL, there is no requirement that they contribute back to the GRASS project. On other hand, diversity in software development approaches can be a very healthy thing. Finally, for anyone interested in porting some of these Java modules back to GRASS I mention a potentially interesting idea. Java or any other language can work with GRASS (In fact part of the work my team is doing involves linking up Java-based ABM with GRASS). However, the current and future versions of GRASS are being optimized to work especially nicely with Python, including the ability to automatically generate a GRASS GUI for any Python script. Object oriented Python has a lot of structural and syntactic similarities to Java. It might not be to hard to port some of these modules to Python. Just a thought to toss out there. Michael On Dec 12, 2009, at 10:01 AM, grass-user-requ...@lists.osgeo.org wrote: Date: Sat, 12 Dec 2009 08:02:13 -0800 (PST) From: Rich Shepard rshep...@appl-ecosys.com Subject: Re: [GRASS-user] Re: Hydroligics in grass To: grass-user@lists.osgeo.org grass-user@lists.osgeo.org Message-ID: alpine.lnx.2.00.0912120759560.4...@salmo.appl-ecosys.com Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Sat, 12 Dec 2009, Michael Barton wrote: That said, we've done a lot of testing in my lab of the ability of these (and other modules like r.flow) to simulate overland flow. We've had the best results with r.watershed with the new multi-flow direction (MFD) algorithm implemented in GRASS 6.5 and 7. Michael, I saw a reference to jgrass in an earlier thread. I've not yet looked closely at it but it apparently has modules lacking in GRASS for precipitation-runoff calculations. Have you or your students looked at jgrass? Ideally, it would be nice to have all the additional capabilities of jgrass incorporated into (C)GRASS. Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: [GRASS-dev] DEM creation from stereo pairs
Michael: Can anyone recommend open source tools for creating a DEM from stereo image pairs? 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. not really what you want, but this is quite interesting: http://www.ecademix.com/JohannesHofmann/gipfel.html Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: [GRASS-dev] DEM creation from stereo pairs
Thanks Hamish On Dec 12, 2009, at 1:40 PM, Hamish wrote: Michael: Can anyone recommend open source tools for creating a DEM from stereo image pairs? 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. 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. not really what you want, but this is quite interesting: http://www.ecademix.com/JohannesHofmann/gipfel.html Not what we are looking for, but cool. Michael ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: [GRASS-dev] DEM creation from stereo pairs
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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: [GRASS-dev] DEM creation from stereo pairs
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 may have a look at http://stereo.sourceforge.net/ or http://grass.itc.it/outgoing/grass5/ best regards Helmut ___ Preisknaller: WEB.DE DSL Flatrate für nur 16,99 Euro/mtl.! http://produkte.web.de/go/02/ smime.p7s Description: S/MIME Cryptographic Signature ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: [GRASS-dev] DEM creation from stereo pairs
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 grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: [GRASS-dev] DEM creation from stereo pairs
Thanks very much. Stereo found ...and in the process of being updated. Michael On Dec 12, 2009, at 4:44 PM, grass-user-requ...@lists.osgeo.org wrote: may have a look at http://stereo.sourceforge.net/ or http://grass.itc.it/outgoing/grass5/ best regards Helmut ___ Preisknaller: WEB.DE DSL Flatrate f�r nur 16,99 Euro/mtl.! http://produkte.web.de/go/02/ -- next part -- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1747 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.osgeo.org/pipermail/grass-user/attachments/20091212/04835588/smime-0001.bin -- Message: 9 Date: Sun, 13 Dec 2009 00:39:04 +0100 From: Christoph H?gl c.ho...@gmx.net Subject: Re: [GRASS-user] Re: [GRASS-dev] DEM creation from stereo pairs To: grass-user@lists.osgeo.org Message-ID: 200912130039.05207.c.ho...@gmx.net 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 grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
