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 169 forks source link

automatic generation of matches from stereo... #263

Closed jchollingsworth closed 10 months ago

jchollingsworth commented 5 years ago

It would be super great if I could launch stereo, and have it end immediately after it generates matches in stage 1 (stereo_corr). Currently, it seems there's no way to have stereo_corr stop after match generation... it continues on to the correlation, which can take a while. (I guess I could sort of achieve this by using --skip-low-res-disparity-comp so it crashes).

I just want the decent, and dense matches for some inter flight-line images to use in bundle_adjust... but I don't need/want to run the full stereo for these inter-line pairs.

Cheers :)

oleg-alexandrov commented 5 years ago

I am a little confused. I think we have interest point matching generation in bundle_adjust. In stereo, we usually create matches in stereo_pprc. We do it in stereo_corr only for for some rather special cases, such as with map-projected images. Which mode do you need this in? I think we should move all interest point functionality to stereo_pprc. The current code has many modes (various sessions, mapprojection on/off, cropped input images off or on) and the functionality developed in a rather haphazard way even before I got to work on it. I cleaned up some over the years (including duplicated code) but more is needed.

jchollingsworth commented 5 years ago

Ah... I see... yes, I was using mapprojected images. I was confused myself, because I thought the IP matching was done in stage 0 pprc.

Sorry for the confusion. Indeed, it would be great if the mapprojected IP matching could happen in preprocessing too.

oleg-alexandrov commented 5 years ago

But if you are using mapprojected images, you cannot use the obtained interest points in bundle adjustment as bundle adjustment expects raw images.

jchollingsworth commented 5 years ago

Can I not use mapprojected-data option in bundle_adjust?

There used to be a way to convert IP matches from mapprojected images to raw geometry.

jchollingsworth commented 5 years ago

I confirm this works... and it's great. Nice stuff Oleg. Thanks for making these awesome tools.

Meantime... if stereo_corr generates matches like so: dem-L_sub__R_sub.match ... is there any way to get these matches back to the original raw image (rather than the sub raw) using mapprojected-data? (I'm guessing you'll say no). ;)

oleg-alexandrov commented 5 years ago

The bundle_adjust tool has a way of going from map projected ip to unprotected ip in the original image. It is called --mapprojected-data and it is even documented with an example in the pdf. It looks like an inane functionality, maybe, but I found it useful for the Moon. I had many very huge images with totally different illuminations and rotations that I could not figure out which is what (like seeking an 100 m area in a 20 km swath). But mapprojected they look perfectly similar.

Let me know if it works for you, I can tweak it if need be.

oleg-alexandrov commented 5 years ago

Ah, sorry, you mean if you can upscale the matches, from L_sub and R_sub to be in respect to the originals. Sorry, indeed, we can't do that. It looks quite exotic. Note however that there is a Python tool floating around on our mailing list to manipulate ASP ip files. One would have to read the matches in, scale them by the ratio of original image size to sub image size, and write them back. Alternatively, which is more awkward, one can do bundle adjustment with the sub images and sub match file while faking the cameras with the option --save-cnet-as-csv which will save the matches as a text file in .gcp format that can be fed back to bundle adjustment after scaling the pixels in it. I know I keep on telling you inane solutions, but what you are asking for is a bit out of the mainstream. We were told by many people to improve python interfaces for our tools, and likely it is a wise thing, since Python nowadays is everywhere.

oleg-alexandrov commented 5 years ago

So maybe at some point things you are asking should be easy to do. I don't know when we will get to it though.

jchollingsworth commented 5 years ago

Ok... Good info. Many thanks!