search

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.
Apache License 2.0
479 stars 168 forks source link

jitter iterations #314

Closed jchollingsworth closed 10 months ago

jchollingsworth commented 4 years ago

Hi...

I know you guys don't like the jitter correction, but sometimes it can be quite effective. However, with the large number of matches used, it can take a very long time run run (I've had the adjustment solver running for many hours, when you can see it's basically converged)... therefore, it would be good to have a few additional options (I think), to speed up and/or improve the adjustments. For example, the ability to use various bundle_adjust options, including: --robust-threshold --parameter-tolerance --max-iterations --num-passes --remove-outliers-params --height-from-dem

These could be passed in like so --piecewise-adjustment-params '--robust-threshold 0.5 --max-iterations 50 --height-from-dem $DEM ' ... or something. I think that could be pretty easy to implement(?).

oleg-alexandrov commented 4 years ago

Yes, one day. Though my primary issue with jitter is that I don't think the current approach I put in is correct. It breaks up a long linesecan sensor into little cameras as the satellite travels and wiggles those cameras without any external constraint. That results in pleasing results without any control of the underlying DEM.

When we get to implement your suggestions that jitter logic should also move out of stereo_tri to its own standalone tool. The stereo_tri was only meant to intersect rays, now it became a fancy optimizer for camera artifacts.

oleg-alexandrov commented 4 years ago

Your suggestions are indeed easy to implement but a pain to test as it requires long images. Hopefully that time will come. Good points.

jchollingsworth commented 4 years ago

Ok... in fact, in some recent tests, I can really well minimize the intersection errors, but in the final DEM, I still have a jitter-type of signal (which you can see if you difference the DEM with a reference). I think it's as you say... when jitter is solved, there are no other constraints, and so you end up at a solution... but it can easily be one that doesn't give a realistic correction.

Given that solving for jitter bears some similarity to refining the distortion in pinhole cameras, AND because the jitter is long-wavelength (i.e. much longer than the resolution of a typical reference DEM), I think that using --heights-from-dem during jitter solving would go a long way to improving the final result.

oleg-alexandrov commented 10 months ago

The old jitter code has been superceded. https://stereopipeline.readthedocs.io/en/latest/tools/jitter_solve.html