stereo -e 4 -t dg --subpixel-mode 1 --corr-seed-mode 3 --alignment-method None 103001001BAA0800_ortho_1.0m_warp.tif 103001001CBA2C00_ortho_1.0m_warp.tif
Writing Point Cloud: dem_ortho_1.0m_warp_spm1/
--> Triangulating: [*********************.........................]
46%libc++abi.dylib: terminate called throwing an exception
NASA Ames Stereo Pipeline 2.2.2_post
Build ID: c7dc89e
NASA Vision Workbench 2.2.0_post
Build ID: 6873c28
Boost C++ Libraries 105300
GDAL 1.11dev | 20130413
All files bundled with the subsampled LiDAR RPC DEM are here:
As solution, we can use the same approach we do for mapproject, but that one is not thread safe. In that case, we could use a lock with multiple threads, or do DEM caching only rather than caching the transform itself (which will slow things down for DG cameras but less for RPC) -- in that case the DEM needs to have its own cache to not have it flushed out by the image cache all the time. A combination of the two is to do DEM caching only for interest point detection, which is not computationally expensive, and do full caching for mapproject and stereo_tri where we know in advance we operate on a per-tile basis rather than per-point basis.
I fixed this. Now both mapproject and stereo_tri use the same (newer code) for going from map-projected image pixels to camera pixels, and can handle no-data in the DEM used for map-projection.
The new code is not thread safe, for reasons too lengthy to explain, but the only places we need to use it does not need that.