neogeographytoolkit / stereopipeline

The NASA Ames Stereo Pipeline is a suite of automated geodesy & stereogrammetry tools designed for processing planetary imagery captured from orbiting and landed robotic explorers on other planets.

Ames Stereo Pipeline (ASP)

The NASA Ames Stereo Pipeline (ASP) is a suite of free and open source automated geodesy and stereogrammetry tools designed for processing stereo images captured from satellites (around Earth and other planets), robotic rovers, aerial cameras, and historical images, with and without accurate camera pose information.

ASP produces cartographic products, including digital terrain models (DTMs, synonymous with digital elevation models, DEMs), ortho-projected images, 3D models, and bundle-adjusted networks of cameras. These data products are suitable for science analysis, mission planning, and public outreach.

• ASP is free software released under the Apache Software License 2.0.
• Documentation: https://stereopipeline.readthedocs.io

Installation

Precompiled binaries (for Linux and macOS) are available for the stable releases and the current development build. Simply download the appropriate distribution for your operating system, extract, and run the executables in the bin subdirectory.

• Stable releases, daily builds, and conda packages

See the NEWS for the most recent additions.

To permanently add the ASP executable subdirectory to your PATH, you can add the following line to your shell configuration (e.g., ~/.bashrc), replacing /path/to/StereoPipeline/bin with the location on your filesystem: export PATH=${PATH}:/path/to/StereoPipeline/bin

ISIS users: Please install the latest USGS ISIS if you would like to process NASA non-terrestrial images. Users wishing to process Earth images, such as Digital Globe, satellites with RPC cameras, or various frame/pinhole cameras do not need to download anything else. If ASP is installed with conda, it will install ISIS in the same environment as well, though it may not be the latest version.

Documentation

The documentation, in HTML format, is at https://stereopipeline.readthedocs.io.

The documentation includes a gentle introduction to using the Stereo Pipeline, an entry for each tool, and example processing workflows for many supported sensors.

The ReStructured Text source files for the documentation are in the docs subdirectory of the ASP distribution.

Support and user community

All bugs, feature requests, user questions, and general discussion can be posted on the ASP support forum.

We also encourage the posting of issues on the GitHub repo (most such items posted on the forum will typically be converted to an issue there for the developers to work on), as well as pull requests.

Credits

ASP was developed within the Autonomous Systems and Robotics area of the Intelligent Systems Division at NASA's Ames Research Center. It leverages the Intelligent Robotics Group's (IRG) extensive experience developing surface reconstruction and tools for planetary exploration (e.g., the Mars Pathfinder and Mars Exploration Rover missions, and rover autonomy). It has also been developed in collaboration with the Adaptive Control and Evolvable Systems (ACES) group, and draws on their experience developing computer vision techniques for autonomous vehicle control systems.

See the list of contributors.

Citation

In general, please use this reference for the Ames Stereo Pipeline:

Beyer, Ross A., Oleg Alexandrov, and Scott McMichael. 2018. The Ames Stereo Pipeline: NASA's open source software for deriving and processing terrain data, Earth and Space Science, 5. https://doi.org/10.1029/2018EA000409.

If you are using ASP for application to Earth Images, or need a reference which details the quality of the output, then we suggest also referencing:

Shean, D. E., O. Alexandrov, Z. Moratto, B. E. Smith, I. R. Joughin, C. C. Porter, Morin, P. J. 2016. An automated, open-source pipeline for mass production of digital elevation models (DEMs) from very high-resolution commercial stereo satellite imagery. ISPRS Journal of Photogrammetry and Remote Sensing, 116. https://doi.org/10.1016/j.isprsjprs.2016.03.012.

In addition to the recommended citation, we ask that you also cite the DOI for the specific version of ASP that you used for processing. Every new release (and daily build) of ASP will have its own unique DOI, which can be found here.

Additional details for how to cite ASP in your published work can be found in the ASP documentation.

License

See LICENSE file for the full text of the license that applies to ASP.

Copyright (c) 2009-2024, United States Government as represented by the Administrator of the National Aeronautics and Space Administration. All rights reserved.

ASP is licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Third-party libraries

This distribution may include some bundled third-party software as a convenience to the user. This software, located in the thirdparty/ directory of the source code release, is not covered by the above-mentioned distribution agreement or copyright. Binary releases distribute third party software in both the bin and lib directories. See the included documentation for detailed copyright and license information for any third-party software or check the THIRDPARTYLICENSES file. In addition, various pieces of ASP depend on additional third-party libraries that the user is expected to have installed.

stereopipeline's Issues

Have ASP produce stereo at lower resolution than the input images

It would be desirable to have stereo output a point cloud at say 2x coarser resolution than the input images. To implement that, one would need to internally sub-sample the input images and scale accordingly the cameras. The scaling of images is trivial, the scaling of the cameras could be achieved by very small modifications to the point_to_pixel(), pixel_to_vector() and camera_center() functions, regardless of camera type.

This is not urgent, I put it here to make sure we don't forget.

Reduce the size of DEMs in ASP

This is related to issue #61, but aimed primarily at reducing the size of DEMs which are final products rather than intermediate data. Some ideas floated around:

• Round DEM values to cm (or user-specified value) and convert to int32 if possible.
• Use predictor flags: predictor=2 for the integer formats
  and predictor=3 for the floating point

Integrate GDAL 1.10 into Binary Builder

GDAL 1.10 is currently on RC3. Once it is actually released (this will probably happen soon), BB needs to switch over to GDAL 1.10 and OpenJPEG 2. This meets one of our deliverables for ASP Earth R2.

Stereo should use a little as possible ImageViewRef

ImageViewRefs puts all lazy operations behind a virtual class. This is slow, but I'm not sure how slow.

So I see these steps:

• Write test to quantify how slow wrapping an operation with a ref is. Quantify if it's worth it.
• Build helper functions in stereo that wrap large chains in a single function call.
• Compare speed before and after changes.

Homography alignment and D_sub search window limits

Still having problems with the homography alignment and D_sub values for unmapped images, even after the spheroid change. I'm seeing good, continuous disparity values in the interior, with bad values near edges/corners, usually on the negative end of the disparity range. The union of these bad values from D_sub H and V propagates to stereo_corr.

The actual alignment appears ok in most cases - not sure if there's much room for improvement there. D_sub H and V often have a "saddle" appearance when alignment isn't great, with bad disparity values in the corners. The issue in these cases may be related to the nonuniform distribution of interest points (clustering near center) used to define the transform. Regardless of the cause, the search window limits used to generate D_sub are insufficient to capture the larger disparity values near corners, and/or there may be an integer rounding issue.

I don't think I can post attachments on github. Emailing screenshot to illustrate...

Change 'no stereo.default file' handling.

If there is no ./stereo.default file, stereo complains and will not run. Is this intended behavior? Two alternatives:

1. If no ./stereo.default file is found, automatically assume the default settings, full auto, and go to town.
2. If there is no ./stereo.default file found, the user should be asked if they want to continue with default settings, or not. If not, stereo quits.

Without these, I have to track down a default stereo.default file to put in my CWD to run stereo, even when I just want to take all the default parameters. I'm probably just being too lazy?

Output files have changed.

It used to be that we wrote out -D.exr, -R.exr, and -F.exr files. In my conversations with Zack they have been changed to just be 32 bit TIFFs now. The /docs/book/outputfiles.tex needs to be updated to reflect the files that stereo is actually spitting out (and also possibly up in the Tutorial section). I didn't feel like was knowledgeable enough to make these changes myself, but wanted to request them.

stereo_mpi needs to be more user friendly

stereo_mpi, the tool to run ASP on multiple machines, needs (I think) to distribute jobs with GNU parallel rather than with mpi_exec. The latter solution only works on the Pleiades supercomputer and only with Intel's mpi_exec.

The biggest issue is that stereo_mpi is untestable, you need to schedule a supercomputer job and have it wait in queue for who knows how long to even do the most basic test.

stereo_mpi also needs a regression test to make sure it does not break when we change stuff, and documentation.

Need Advanced Tutorial

This tutorial should use the example stereo data available from Digital Globe.

• It should show how NONE, HOMOGRAPHY, AFFINEEPIPOLAR, NONE (+rpc_mapprojected imagery) compare in run time.
• It should have a subsection in there that discusses compositing the DG subframes together to run stereo. Take note to explain that rpc_mapprojection is no longer possible in that case.
• This section should introduce stereo_mpi and its application to super computers.
• This section should also introduce dem_geoid and referencing DEMs to a geoid.
• This should also show current research in alternatively producing a d_sub from Ben's python code and via DEM.

This chapter is targeting researchers and the professional community. It should be okay to use technical terms that might be confusing to the layman.

Change 'errors' terminology

The new triangulation errors features in ASP need to have their options renamed. At the moment, they are mostly just called 'errors' and that might cause a user to interpret them as more than they are.

The --errorimage option for point2dem has good help text, but could optionally be renamed --trierrorimage or something.

Similarly, it outputs a file named *-DEMerrors.tif that should probably be *-DEMtrierrors.tif or something similar.

ASP Binaries need to ship Proj4's share directory.

The Proj4 share directory contains extra information about datum conversions. We require this if we wish to fully support Earth users.

Affine Epipolar Rectification needs documentation

ASP make check fails if ISIS is turned off

Apparently if ASP is built with ISIS off, when one runs 'make check', the following error shows up:

Symbol not found: __ZTVN2vw21DiskImageResourceIsisE
Referenced from: StereoPipeline/src/asp/Sessions/.libs/
libaspSessions.4.dylib

The solution may be to split all ISIS-related stuff into its own library. This was reported by Ben and I did not try to reproduce it.

The stereo python script truncates negative numbers

If I try to run the python script wrapper as follows:

stereo --some-text -456

then this thing passes to stereo_pprc the following:

stereo_pprc --some-text -4

I don't see this is as a problem for now, but it may be in the future. Note that positive numbers are passed in correctly.

IsisCameraModel not copy constructible

If you copy construct an IsisCameraModel, you will get memory leaks. Perhaps use boost::sharedptr's to hold the pointers?

TIFF size exceed on Preprocessing

Specifically it appears that BigTIFF is not turned on.

stereo PSP_006941_1825_RED.map.norm.equ.cub PSP_007732_1825_RED.map.norm.equ.cub result/output
*************************************************************
Reading Stereo Settings file: ./stereo.default
*************************************************************
--> Detected ISIS cube files.  Executing ISIS stereo pipeline.
--> Using standard Isis camera model: PSP_006941_1825_RED.map.norm.equ.cub
--> Using standard Isis camera model: PSP_007732_1825_RED.map.norm.equ.cub

[ 2010-Jun-30 22:32:02 ] : Stage 0 --> PREPROCESSING 
ERROR 4: `result/output-L.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

--> Computing statistics for the left image
   Left: [ lo:0.627511 hi:1.29762 m: 1.00268 s: 0.0558677]
--> Computing statistics values for the right image
   Right: [ lo:0.66076 hi:1.30991 m: 1.00139 s: 0.0580173]
--> Normalizing globally to: [0.627511 1.30991]
--> Writing normalized images.
            Left:  [*************************************************.....] 91%ERROR 1: TIFFAppendToStrip:Maximum TIFF file size exceeded
ERROR 1: TIFFAppendToStrip:Maximum TIFF file size exceeded

Filter low-res disparity

If low-res disparity has gross errors, it can make the run-time explode. Filtering is desired.

Notes:

1. It would be nice to have a testcase.
2. Can the filtering function used in disparity post-processing be used? My impression was that it did not deal with outliers.
3. May need to filter disparity even later, such when going say from level 3 to level 2 in full-res calculation. It is at such a stage in case of snow images that more detail comes into view and the disparity can get seriously confused.
4. May need hole-filling in addition to filtering at each step (save perhaps the last). After all, disparity is meant to be continuous. Hole-filling should be cheap at high levels of the pyramid.
5. Before doing any work it would be good to look at the literature.

Local Homography needs Documentation

geodiff could be made faster

Given two DEMs, A.tif and B.tif, the command

geodiff A.tif B.tif

can be hundreds of times slower than

geodiff B.tif A.tif

That happens if A.tif covers a huge area but B.tif a smaller one. I think geodiff could be more clever in first finding the intersection of the bounding boxes of the two images and finding the diff only in that area.

More seriously, geodiff A.tif B.tif returned an empty result (after all that work), while the reverse returned a good result. Perhaps it is because the grids were different.

I'll perhaps get to fixing this issue myself at some point, I put it here to make sure it is not forgotten.

Pinhole Session not Triangulating correct

Using the Apollo Camera models with AdjustableTsai distortion does not appear to be working correctly. The imagery used where AS15-M-1950.lev1.cub and AS15-M-1951.lev1.cub. The camera models were extracted using my Apollo Metric Processing kit
.

stereo's -v option not working

Using
~/StereoPipeline-x86_64-redhat6.2-2012-05-25_11-33-023c82584/bin/stereo -v

Instead of getting a neat version string, as expected, I get:

Error parsing input:
missing required option left-camera-model
Usage: /home/rbeyer/StereoPipeline-x86_64-redhat6.2-2012-05-25_11-33-023c82584/libexec/stereo_pprc [options] <Left_input_image> <Right_input_image> [Left_camera_file] [Right_camera_file] <output_file_prefix> ...

RPC session with map-projection is broken

Usually we use the RPC model just to map-project the images. The actual stereo uses the DG session and cameras. I tried using the RPC session for the whole process and I get a DEM in the wrong place with the wrong height. To be looked into.

Imrovements in building ASP

Proposed changes/fixes to to the ASP BinaryBuilder tool:

1. Internally build the little tool named chrpath rather than dying on the spot saying it is not available. It takes a lot of digging to finds its source, and it is trivial to have the Builder take this burden from the developers (which include me, our future hire, and the UW folks who regularly compile our stuff).
2. Have BinaryBuilder remember which packages it already built, so if it dies in the middle, and it gets resumed, it should not start from the beginning.
3. Check when building for OSX that gcc can build Objective-C and Objective-C++ code. OpenSceneGraph needs that and causes ASP to fail.

References to Bandnorm and Equalizer should be removed from Documentation

These are no longer required to produce best results when processing ISIS imagery.

Something is messed up with the build system

I have encountered an issue, which I may fix myself at some point, although for now I have no idea where it comes from.

I have a program, dem_adjust, in asp/srs/Tools. It depends on geographylib. Both this program and its depending library have include flags of the form:

PKG_DEM_ADJUST_CPPFLAGS
PKG_GEOGRAPHICLIB_CPPFLAGS

The flag PKG_DEM_ADJUST_CPPFLAGS does not get passed dem_adjust when it is being built, as it should, that is bad. However, the flag PKG_GEOGRAPHICLIB_CPPFLAGS does gets passed to dem_adjust, since dem_adjust depends on this library.

So I used this workaround, but it it still somewhat annoying that a given flag specified for a given program does not get passed to it when building it.

Large memory usage in pre-processing

I've seen the memory usage in stereo_pprc shoot up north of 10GB for large images. I think it happened in image sub-sampling. I'll take a look later.

Least squares triangulation issue

Something is funny with how triangulation happens when least squares point determination (given the two rays) is turned on. On different machines the answer can be wildly different. This mode is barely, if ever, used, but it should be investigated.

Make stereo parallel by default

There are two wrappers around the stereo executables: stereo and parallel_stereo. The second one does the same thing as the former, but in addition can take the optional --nodes-list option which allows it to replicate itself on multiple machines. (There are a couple more of optional finer grained control options).

The proposal is to rename parallel_stereo to stereo. The user won't notice any change in behavior for the new version of stereo.

Some care and thought is needed here as to how to best interpret user's intention. For example, in ISIS mode, if the user wants to use 8 threads, for triangulation we can under the hood use 8 processes with 1 thread each instead and get a free speedup. Now we ignore user's request anyway as triangulation is single-threaded for ISIS.

The goal here is to gradually have the user adopt the mindset of using stereo over multiple machines. Networked hardware is easy to come by and datasets, at least for DG, are getting huge.

Reduce size of ASP outputs

There are two proposals here:

1. Save point clouds as float32 instead of float64, with offsets in a separate metadata file. Imitating LAS somewhat. This will cut in half the file size, with little or no precision loss. Care needs to be taken here with outliers (ASP tends to create those), presumably the median is a good location for the point cloud center. Pixels which overflow the float precision can be safely set to no data.

The existing flow can be preserved for backward compatibility as an option: --gen-float64-point-cloud

1. Less critical, compress or get rid of mask band in RD.tif and F.tif. This will reduce these files by a third.

Example: For an image of size 13777 by 21684, one has:

994M run-R.tif
2.1G run-F.tif
2.2G run-RD.tif
7.8G run-PC.tif

Multithreaded Triangulation for ISIS

The idea is simple but the implementation is tricky. ASP should mutex all interactions it has with ISIS as that code is not thread safe. The design should probably follow VW's implementation of the GDAL resource (which is another non-thread-safe library). However since the uses of ISIS resources are kinda scattered through out the code, a global mutex will be required. I was thinking of hiding it inside a isis_settings struct much like how vw_settings exists.

No-data values with ISIS images

When pre-processing ISIS images, ASP has been for a long time setting pixel values below the smallest valid pixel value to this smallest valid pixel value.

This is not the correct approach, those values need to be set to no-data. This however causes a lot of erosion when transforming images (e.g. homography alignment), as when an image is warped, interpolating at a location which has as a neighbor an invalid pixel results in an invalid value.

That is to say, if the correct approach is implemented, users will suddenly start seeing DEMs with quite a bit of pixels missing at the borders of the valid region. The current incorrect approach has been in use for a long time without problems.

We need to decide at some point the trade-offs between fixing this or leaving it the way it is. This would require a good amount of experimentation.

RPC Mapproject needs a Safety check

One of our users was able to invoke the following error listed below. This was likely due to them projecting an image directly on the boundary of their input DEM. If possible can we have rudimentary check to make sure the that outline of the input RPC image is entirely inside the DEM projection? A more concrete solution would be projecting the image boundaries on the DEM and at least verifying that the DEM has valid pixels at those extremas.

rpc_mapproject --t_srs '+proj=utm +zone=47 +north +datum=WGS84' --tr=1 --threads=12 DEM.tif WV01.tif WV01.xml WV01_rpc_mapped_1m.tif
--> Setting number of processing threads to: 12
Output Georeference:
-- Proj.4 Geospatial Reference Object --
Transform : Matrix3x3((1,0,502411)(0,-1,8.78538e+06)(0,0,1))
Geodeditic Datum --> Name: WGS_1984 Spheroid: WGS 84 Semi-major: 6.37814e+06 Semi-minor: 6.35675e+06 Meridian: Greenwich at 0
Proj.4 String: +proj=utm +zone=47 +units=m
Pixel Interpretation: pixel as area

Creating output file that is Vector2(22068,21476) px.
[***************************************************......................] 70%Error: Cannot allocate enough memory for a 22948087x50508x1 image: too many bytes!
terminate called after throwing an instance of 'vw::ArgumentErr'
what(): Cannot allocate enough memory for a 22948087x50508x1 image: too many bytes!
Aborted (core dumped)

Investigate Fixed Precision Disparity Maps

I'm not sure we need the precision of a full floating point disparity in ASP. Possibly only a tenth or a hundredth precision is required.

What this would provide is better compression by TIFF for F and RD disparities. This would also allow lossless compression using JPEG 2000 and Jasper. Sadly, none of that is thread safe.

Added ULLA feature to Point2dem/RPC_mapproject

Allow the user to crop the orthoprojection to some map-projection coordinate.

Binary Builder fails to build ISIS on latest Ubuntu

Superlu linking fails when compiling ISIS in Binary Builder. This is required to produce our AVX supporting builds of ASP.

Have ASP generated DEMs relative to geoid

We already have the tool dem_geoid (in the upcoming release) which can convert a DEM from being relative to a datum ellipsoid to being relative to a geoid (or areoid on Mars). I'd argue it would be nice for point2dem to directly generate output to be in relative to the geoid (say with a --geoid command line option).

An issue I can see is whether one can tell from the DEM later what it was generated in reference to. There may be a label perhaps somewhere.

Aquire Apache 2 License

This is still sitting in the lawyer office at NASA Ames Research Center.

Make orthoproject parallel

orthoproject is painfully slow for ISIS, as it can only be single-threaded. This tool is trivial to parallelize to run with multiple processes and even on multiple machines using the Python infrastructure we already have for parallel_stereo. I have already extensively used such a tool written in Perl, so the proof of concept is there.

The current orthoproject executable will be stashed away in libexec, and the new Python wrapper with the same name will take its place. The users won't notice any difference except it becoming say 8x faster. If the user uses the --nodes-list option, it will automatically distribute itself on multiple machines.

VW's FileIO unit tests segfault with Clang 3.1 and GCC 4.7

The error seems to be buried inside GDAL 1.9.1. To reproduce the error, build VW like normal from Binary Builder. Then run:

cd $VW/src/vw/FileIO/tests
libtool --mode=execute valgrind TestDiskImageResource

You'll see a list of errors from Valgrind that sometimes and sometimes does not cause the system to segfault. Here's an excerpt of the badness:

Loading: TestDiskImageResource.cxx
==1802== Conditional jump or move depends on uninitialised value(s)
==1802==    at 0x67AD331: __GI___strncasecmp_l (strcmp.S:243)
==1802==    by 0x675F7EA: ____strtod_l_internal (strtod_l.c:585)
==1802==    by 0x76DC620: DOQ1Dataset::Open(GDALOpenInfo*) (stdlib.h:281)
==1802==    by 0x7864C12: GDALOpenInternal(GDALOpenInfo&, char const* const*) (gdaldataset.cpp:2236)==1802==    by 0x7864D81: GDALOpenInternal(char const*, GDALAccess, char const* const*) (gdaldataset.cpp:2208)
==1802==    by 0x4F22F9E: vw::DiskImageResourceGDAL::open(std::string const&) (DiskImageResourceGDAL.cc:251)
==1802==    by 0x4F265F4: vw::DiskImageResourceGDAL::DiskImageResourceGDAL(std::string const&) (DiskImageResourceGDAL.h:68)==1802==    by 0x4F2582C: vw::DiskImageResourceGDAL::construct_open(std::string const&) (DiskImageResourceGDAL.cc:559)  
==1802==    by 0x430510: DiskImageResource_WrongFiles_Test::TestBody() (TestDiskImageResource.cxx:351)==1802==    by 0x49B117: void testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (gtest-all.cc:3394)==1802==    by 0x495F0F: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (gtest-all.cc:3430)
==1802==    by 0x4827C0: testing::Test::Run() (gtest-all.cc:3466)
==1802==
==1802== Conditional jump or move depends on uninitialised value(s)
==1802==    at 0x67AF857: __GI___strncasecmp_l (strcmp.S:2255)
==1802==    by 0x675F7EA: ____strtod_l_internal (strtod_l.c:585)==1802==    by 0x76DC620: DOQ1Dataset::Open(GDALOpenInfo*) (stdlib.h:281)
==1802==    by 0x7864C12: GDALOpenInternal(GDALOpenInfo&, char const* const*) (gdaldataset.cpp:2236)==1802==    by 0x7864D81: GDALOpenInternal(char const*, GDALAccess, char const* const*) (gdaldataset.cpp:2208)==1802==    by 0x4F22F9E: vw::DiskImageResourceGDAL::open(std::string const&) (DiskImageResourceGDAL.cc:251)==1802==    by 0x4F265F4: vw::DiskImageResourceGDAL::DiskImageResourceGDAL(std::string const&) (DiskImageResourceGDAL.h:68)==1802==    by 0x4F2582C: vw::DiskImageResourceGDAL::construct_open(std::string const&) (DiskImageResourceGDAL.cc:559)  
==1802==    by 0x430510: DiskImageResource_WrongFiles_Test::TestBody() (TestDiskImageResource.cxx:351)==1802==    by 0x49B117: void testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (gtest-all.cc:3394)
==1802==    by 0x495F0F: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (gtest-all.cc:3430)
==1802==    by 0x4827C0: testing::Test::Run() (gtest-all.cc:3466)
==1802==
==1802== Use of uninitialised value of size 8
==1802==    at 0x67AF859: __GI___strncasecmp_l (strcmp.S:2257)
==1802==    by 0x675F7EA: ____strtod_l_internal (strtod_l.c:585)==1802==    by 0x76DC620: DOQ1Dataset::Open(GDALOpenInfo*) (stdlib.h:281)
==1802==    by 0x7864C12: GDALOpenInternal(GDALOpenInfo&, char const* const*) (gdaldataset.cpp:2236)==1802==    by 0x7864D81: GDALOpenInternal(char const*, GDALAccess, char const* const*) (gdaldataset.cpp:2208)
==1802==    by 0x4F22F9E: vw::DiskImageResourceGDAL::open(std::string const&) (DiskImageResourceGDAL.cc:251)==1802==    by 0x4F265F4: vw::DiskImageResourceGDAL::DiskImageResourceGDAL(std::string const&) (DiskImageResourceGDAL.h:68)==1802==    by 0x4F2582C: vw::DiskImageResourceGDAL::construct_open(std::string const&) (DiskImageResourceGDAL.cc:559)  
==1802==    by 0x430510: DiskImageResource_WrongFiles_Test::TestBody() (TestDiskImageResource.cxx:351)==1802==    by 0x49B117: void testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (gtest-all.cc:3394)
==1802==    by 0x495F0F: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (gtest-all.cc:3430)
==1802==    by 0x4827C0: testing::Test::Run() (gtest-all.cc:3466)

Request dem2mesh

A utility that could create an OSG mesh from DEM files such as our geotiffs.

Add documentation on Affine Epipolar rectification

point2mesh doesn't write its temporary files in pwd

If the out-PC.tif and out-L.tif files are in some /some/other/directory/, and not in pwd, when you run point2mesh it tries to write its temporary file, out-L-tex.tif, to /some/other/directory/ instead of pwd. If you can't write to /some/other/directory, point2mesh just fails.

Can this be changed so that the temporary files are written to pwd.

Bus error / Segfault on Stereo_Fltr

Reported by Shean:

Stereo Session: DG
System: OSX 10.6 64 bit
Build: Local Custom

This happens specifically on the Good Pixel Map generation step:

NASA Ames Stereo Pipeline 2.0.0_pre
Build ID: b99882a

Built against:
NASA Vision Workbench 2.2.0_post
Build ID: 99860e5
Boost C++ Libraries 104800
GDAL 1.9.0 | 20111229
Proj.4 470

stereo_fltr -t dg --threads=7 -s dem/WV02_11FEB241515255-P1BS-1030010009C65700__WV02_11FEB241514058-P1BS-1030010009B0B500/stereo.default dem/WV02_11FEB241515255-P1BS-1030010009C65700__WV02_11FEB241514058-P1BS-1030010009B0B500/WV02_11FEB241515255-P1BS-1030010009C65700.tif dem/WV02_11FEB241515255-P1BS-1030010009C65700__WV02_11FEB241514058-P1BS-1030010009B0B500/WV02_11FEB241514058-P1BS-1030010009B0B500.tif dem/WV02_11FEB241515255-P1BS-1030010009C65700__WV02_11FEB241514058-P1BS-1030010009B0B500/WV02_11FEB241515255-P1BS-1030010009C65700.xml dem/WV02_11FEB241515255-P1BS-1030010009C65700__WV02_11FEB241514058-P1BS-1030010009B0B500/WV02_11FEB241514058-P1BS-1030010009B0B500.xml dem/WV02_11FEB241515255-P1BS-1030010009C65700__WV02_11FEB241514058-P1BS-1030010009B0B500/WV02_11FEB241515255-P1BS-1030010009C65700__WV02_11FEB241514058-P1BS-1030010009B0B500
--> Setting number of processing threads to: 7

[ 2012-Apr-26 01:14:44 ] : Stage 3 --> FILTERING
--> Cleaning up disparity map prior to filtering processes (1 pass).

    --> Good Pxl Map: [...............................................] 0%Bus error

22.476u 4.313s 0:22.49 119.0% 0+0k 0+3io 1051pf+0w
Failed

Executables to add to ASP

ASP needs to add to its hidden tools directory (libexec) two dependencies:

1. gdal_translate, used in preview mode by dg_mosaic
2. GNU parallel, used by parallel stereo

Cache doesn't seem to be releasing handles

Take a large image and then save it as a TIFF with TILED set to 'no'. This causes the internal structure of the TIFF to be tiles that are 64 px tall and then the full image width wide. Give this to stereo_pprc and this invokes a bunch of warning messages like:

Warning: Cached object (143360) larger than requested maximum cache size (805306368). Current Size = 808287560

Likely this is due to DiskImageView or our cache system not releasing cache handles. It should be reproducible in small scale as a unit test inside VW.

Output Prefix and Settings from Command Line

Using the MOC demo, running:

stereo --corr-kernel 25,25 --subpixel-mode 2

This causes the mistake where the output prefix is "2" instead of . Most like a Boost Program options problem. This was reported in ASP 2.0 which used Boost 1.46. Current development code is using Boost 1.50 and this problem still persists.

Camera Point warning is wrongly going off for K10

The warning I'm talking about is:

../../bin/stereo left4.png right4.png black_left.tsai black_right.tsai results/k10black
        --> Detected pinhole camera files. Executing pinhole stereo pipeline.
Warning: Your cameras appear not to be pointing at the same location!
        A test vector triangulated backwards through
        the camera models. You should double check
        your input models as most likely stereo won't
        be able to triangulate.
Using "./stereo.default"

I believe this has something to do with recent refactoring that's been going on.

RPC Triangulation

We need an RPC mode and triangulation support for it. User interaction would look something like the following:

stereo left.tif right.tif left.xml right.xml output/prefix -t rpc

It could optionally auto detect from:

stereo left.tif right.tif output/prefix

The above could work because some digital globe / geoeye images record the RPC information in their file headers. We already have read support in RPCModel.h (we're using GDAL as an access method).

Integrate sparse_disp into ASP

After discussing this with Zack, we would like to integrate sparse_disp into the python scripts, stereo and stereo_mpi. We'll get to it after the release.

We are still reluctant however to document and advertise this feature yet, for the following reasons:

1. sparse_disp depends on a large number of Python modules (numpy, scipy, multiprocessing, gdal, gdalconst). Particularly numpy and scipy (and I think gdal as well) need to be compiled for user's specific version of python, so we can't ship these. (The alternative, writing sparse_disp in C++, would introduce its extra dependencies, make the code hard to read/maintain, without probably making it faster.)
2. It only works for geo-referenced images.
3. We are not sure the software is mature enough.

Item 1 is by far the biggest issue.

Once it is integrated into ASP it would make it easier for you folks to use it, and time will show what happens next.

Subpixel Mode 3 uses excessive memory

Processing CTX pairs causes errors for user in OpenSUSE 64 bit and in OSX. Error in OSX says:

@ row 450: average pixel took 113.702 over 421789 pixels
@ row 650: average pixel took 107.02 over 574511 pixels
/isis3/isis/bin/stereo: line 28: 3005 Bus error "${LIBEXEC}/$(basename $0)" $*

My guess is that Alex's debug code is still deeply embedded and is the cause of this excessive use of memory.