Persisting disparity after aligning with MOLA

[Janko Trisic Ponce]

Hi all, 

I'm currently creating a CTX DTM from a stereopair, aligned with the overlapping MOLA shots by using pc_align. I've reduced the disparity in altitude between the MOLA and DTM to an average of ~5m, but there is an area in the centre of the DTM where it goes up to +20m. At first, I thought it was a product of jitter, as the higher disparity area coincided with an area where the intersection error spikes up, but even after correcting for jitter, it persists; I have tried using different algorithms (asp_sgm and asp_bm), and the disparity area is exactly the same. 

I'm beginning to think it might be a processing error, perhaps related to the kernels used in spiceinit, but I'm not sure and I wouldn't know how to fix it if it were so. I'm attaching a pdf with the commands I used as well as images related to what I'm referring to, the .csv containing the mola shots and a .gpkg file to project them onto qgis. Am I missing something? Did I do a misstep at some point? Any tips/recommendations will be greatly appreciated!

Thank you, 

Janko

[Oleg Alexandrov]

Janko,

Your process looks good. 

I don't think it is an issue with spice kernels, as those will result in much bigger problems.

When you solve for jitter, you use as a constraint the DEM that you just made (after alignment), which has jitter relative to MOLA, so then the jitter cannot go away. I think that may be the source of the problem.

Then, you did not specify --heights-from-dem-uncertainty, which then defaults to 10.0, which may be a little too tight for CTX. Maybe a value such as 50 will work better (the CTX doc says 20, which should be fine too I think). This is a minor thing here though.

It is also important to note that our jitter solver has some limitations, but you should be able to do better than shown here (https://stereopipeline.readthedocs.io/en/latest/tools/jitter_solve.html#limitations).

When solving for jitter the DEM to constrain against should perhaps another independent DEM that is consistent with MOLA. One could perhaps in-fill MOLA for that, but MOLA is way too sparse.

My suggestion would be to first try another stereo pair for that area (there are plenty for CTX). One should ensure the stereo convergence angle is about 20-40 degrees, and the images have similar illumination.

Perhaps, if you do another stereo pair, and that DEM can be aligned to MOLA as well, then those two DEMs you have could be merged and one could see how this one differs against MOLA, and if solving for jitter with the merged DEM gives a better result.

In principle, one could solve for jitter jointly from 4 images. One could use two dense match files (from each stereo pair) and sparse matches for the rest of pairs, as produced by bundle_adjust. These would need to have the same naming convention.

So, likely jitter cannot be made to go away altogether, but with more images and a better DEM constraint one could get improved results.

Happy to hear how this works out for you.

Oleg

--
You received this message because you are subscribed to the Google Groups "Ames Stereo Pipeline Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ames-stereo-pipeline...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ames-stereo-pipeline-support/bb52296f-9d72-446a-9666-26392116192an%40googlegroups.com.

[Trisic Ponce, Janko]

Hi Oleg, 

Interesting, I will definitely try this out! When choosing the stereopairs, I did choose a pair with similar illumination and a convergence angle of 30 degrees; there didn't seem to be any more with larger angles covering the area I was interested in. I will do another DEM with a slightly smaller convergence angle and try to use that as a constraint for jitter, and see how it goes.

I really appreciate your help, 

Janko