Closed jessemapel closed 2 years ago
I found out why the MiniRF dataset I had from Trent has been producing unsatisfactory results. The stereo convergence angle of the stereo pair LSZ_01636_1CD_XKU_09N120_S1.8bit.cub LSZ_02330_1CD_XKU_00S120_S1.8bit.cub is just 3.48 degrees. And the overlap is little. I do get some reasonable narrow and long terrain but it is a little too noisy. Here's a screenshot of the DEM and orthoimage.
I think the observation regarding the convergence angle is an important insight. One should always check it. Recent ASP prints this angle on the screen during the first stereo step (preprocessing).
I spent almost a full day trying to find better datasets. I processed around 30 .IMG files at various locations, with each dataset up to 2 GB in size. None had a good stereo convergence angle.
It looks to me that MiniRF was not designed to do stereo. It is meant to do effective coverage, so I guess the sensor always travels and also points the same way, and only by some luck images overlap one gets some semblance of stereo.
Later I found a rare (and apparently intentional) stereo dataset based on Randy's paper https://meetingorganizer.copernicus.org/EPSC-DPS2011/EPSC-DPS2011-1473.pdf. This is for the Jackson crater. Based on that, I got the pair: lsz_03821_1cd_xku_16n196_v1.cub lsz_03822_1cd_xku_23n196_v1.cub.
However, generating CSM camera models fails with SPICE errors because of missing kernels. I put a longer note at the bottom of https://github.com/USGS-Astrogeology/ale/issues/423.
I think Trent's earlier MiniRF dataset is good enough (now that we know where its weakness is), to continue investigating the ISIS vs CSM implementations.
The bigger problem is that MiniRF produces curved rays, so we won't be able to support it correctly in ASP out-of-the-box. (https://github.com/USGS-Astrogeology/usgscsm/issues/372) Two straight rays are easy to triangulate. For curved rays one has to do some kind of iterative approach to find where they meet. That will be slow. And MiniRF is a big sensor, with each image having on the order of 2219 x 64825 pixels.
This new ray intersection logic should not be a lot of work but I am not sure of the payoff at this stage. I will think of this
more in the coming days.
BTW, Randy's paper above says about the Mini-RF DEM that
"Comparison of the stereo DTM with ~250 m/post LOLA grid data revealed (in addition to dramatically greater detail) a very smooth discrepancy that varied almost quadratically with latitude and had a peak-to-peak amplitude of nearly 4000 m. In addition, the bundle adjustment residuals in the north-south direction were ~3x higher than for the image set in Cabeus crater that we had previously controlled [2] and these residuals also varied systematically as a smooth, almost cubic function of latitude having a peak-to-peak amplitude of 6 pixels (~90 m). "
So likely the SAR implementation in SOCET SET has its issues, if not fundamentally the SAR modeling itself, which is another argument for not researching this sensor too deeply.
I'm going to close this as done. I think the King Crater and Jackson Crater data sets are sufficient for this.
For the record, the new example was tested, bugs ironed out, and updated documentation is available at: https://stereopipeline.readthedocs.io/en/latest/examples.html#the-usgs-csm-sar-sensor-for-lro-mini-rf
We currently have a test data set of King's Crater but in initial stereo testing, it produced a very noisy DEM. Look for a better test data set for stereo DEM generation.