Squares and ripples in DEMs?

[christina Toldbo]

Hello again

A curious question. I have a model made from two images that looks like the attached (named squares). it is made using the stereo.default attached. 

If I change the rectification method to 'homography' I still have squares but I also get ripples (see attached)

I was just wondering what these features result from? What they may indicate or which setting(s) may be responsible and how can I improve them.

Thank you again!

Christina

[Oleg Alexandrov]

I think the asp_mgm algorithm (rather than asp_bm) together with subpixel-mode 2 (which you seem to be using) may make them go away. You can also try smoothing that DEM, map-projecting onto it both images at same resolution, and redoing stereo will help too. See https://stereopipeline.readthedocs.io/en/latest/next_steps.html#running-stereo-with-mapprojected-images.

[Oleg Alexandrov]

And just to add, sometimes the artifacts can be data-dependent. I ran into a situation recently where one produced DEM was good and another one worse, but all datasets were from the same camera at the same location. The worse DEM had images with small stereo convergence angle (as printed by stereo_pprc) and somewhat differing illumination. Not sure now which of the two things contributed more to the artifacts. 

[christina Toldbo]

Thank you again for your answer. 

I had trouble using the MGM because my pc ran out of memory (happens if I have subpix 3 and a correlation kernel size smaller than 9.)

It works with subpix 2 and corr kernel size, 5, 7 and 9 if i set the threads to 4 (I am running locally on a mac) :) I do indeed get a more smooth surface without the squares. However, it created some new questions. 

1. Is there a 'standard' stereo.default file example for MGM and SGM I can use? If I do not specify a file and simply run: 'parallel_stereo left.cub right.cub --stereo-algorithm asp_bm /resultFolderMGM' then it somehow finds the stereo.default file on my system and when I check the stereo.default in the debug it has asp_bm selected.

2. Related to the first question, I have made my own stereo.default file consisting of:

alignment-method local_epipolar
stereo-algorithm asp_mgm
corr-kernel 5 5  
cost-mode 4
median-filter-size 3
subpixel-mode 2
subpix-from-blend
skip-point-cloud-center-comp
corr-seed-mode 1
sgm-collar-size 0
threads 4 

But is the MGM solution rectified the same way as in the BM solution? I see in the documentation that I should set the 'alignment-method local_epipolar' when running MGM but the BM default.stereo has NONE , EPIPOLAR,  HOMOGRAPHY and AFFINEEPIPOLAR. Should MGM still have one of these? 

3. It says in most of the documentation that the MGM and SGM produces higher quality results than BM. What is that based on? Visual inspection or is there another parameter? I notice that the triangulation error remains the same regardless of if I use BM or MGM and that the MGM geotiff is less dense (as if it is "just" smoother). When I compare the BM 'standard' (using the standard settings from stereo.default) with MGM using the above parameters in (2.) and geodiff I get the attached map with differences of more than 100 m which seems to not be related to the squares. Is there any argument for trusting one model over the other?

Sorry for all my questions, I am very grateful that you are taking the time to answer.

best,

Christina

[Oleg Alexandrov]

I had trouble using the MGM because my pc ran out of memory (happens if I have subpix 3 and a correlation kernel size smaller than 9.)

You need to lower the number of processes with MGM, to maybe 1/4th of the number of cores, if you use 4 threads. The default with the daily build is now 8 threads and the number of processes is the number of cores over 8. Also see the option --corr-memory-mb in https://stereopipeline.readthedocs.io/en/latest/stereodefault.html, and then a longer writeup in https://stereopipeline.readthedocs.io/en/latest/next_steps.html#dealing-with-long-run-times.

 

1. Is there a 'standard' stereo.default file example for MGM and SGM I can use? If I do not specify a file and simply run: 'parallel_stereo left.cub right.cub --stereo-algorithm asp_bm /resultFolderMGM' then it somehow finds the stereo.default file on my system and when I check the stereo.default in the debug it has asp_bm selected.

You need to edit your stereo.default and set in there what you want. Or delete that file and set all options from the command line. One needs to prepend two dashes to anything set on the command line.

 

But is the MGM solution rectified the same way as in the BM solution? I see in the documentation that I should set the 'alignment-method local_epipolar' when running MGM but the BM default.stereo has NONE , EPIPOLAR,  HOMOGRAPHY and AFFINEEPIPOLAR. Should MGM still have one of these? 

There are two versions of MGM. One is ASP_MGM, which is our implementation, and second is the original author MGM. That is written somewhere in the stereo algorithms section. Our ASP_MGM algorithm will work with any alignment method. The original MGM, which is very slow, btw, will work only with local_epipolar alignment. 

I now edited the stereo.default.example file shipped with ASP and added mention of local_epipolar. 

 

3. It says in most of the documentation that the MGM and SGM produces higher quality results than BM. What is that based on? Visual inspection or is there another parameter? I notice that the triangulation error remains the same regardless of if I use BM or MGM and that the MGM geotiff is less dense (as if it is "just" smoother). When I compare the BM 'standard' (using the standard settings from stereo.default) with MGM using the above parameters in (2.) and geodiff I get the attached map with differences of more than 100 m which seems to not be related to the squares. Is there any argument for trusting one model over the other?

Yes, visual inspection is used a lot for this. Normally, the difference between MGM and BM should be small if the terrain has very good texture. If not, the BM algorithm can get confused, because it matches small patches among left and right images and if those are not unique it may fail. The ASP_MGM algorithm does a semiglobal approach, so it  tries to use the larger neighborhood as a context when deciding how to find the correlation in areas of poor texture. Sometimes this algorithm is overeager and fills in the texture where it is best to just put nothing.

[Scott McMichael]

Note that ASP_MGM (not sure about MGM) has its own built-in subpixel step (mode 7 by default) that is overwritten when you use subpixel mode 2.  If you set subpixel mode to 7 you should see more of a difference between the MGM results and the BM results.  You can also try cost mode 3 with ASP_MGM, sometimes that produces better results than mode 4.

Scott

--
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 on the web visit https://groups.google.com/d/msgid/ames-stereo-pipeline-support/CADDkNmO9cQ1w7cv1tX4aFNoevB%3DJa3EWZPXZ%2BvBiH7fa2OWoFw%40mail.gmail.com.

[christina Toldbo]

Thank you Oleg and Scott

You need to lower the number of processes with MGM, to maybe 1/4th of the number of cores

I now set '--processes 4 --threads-multiprocess 4' in the call. It runs, can I assume it runs correctly if it does not throw an error?

Thank you for the clarification on the alignment methods. It seems to me that local epipolar and affine epipolar gets the same result.

Normally, the difference between MGM and BM should be small if the terrain has very good texture.

ok, I have attached my image pair and to me they seem to have alright texture? (I am a beginner so maybe not). I also looked into the things you wrote about convergence angle and it is indeed smaller than advised. However, they create a 'nice DEM' and if I use another pair with better convergence angle, I get a lot of holes and artifacts (also attached). I guess I can use the holy DEM and project and smooth and all this, but what is more correct? A smooth solution with poor convergence angle or a 'patched' solution with a good convergence angle?

has its own built-in subpixel step (mode 7 by default) that is overwritten when you use subpixel mode 2

Haha if I use that (ie. 7) I get the attached DEM which is quite strange

If you set subpixel mode to 7 you should see more of a difference between the MGM results and the BM results

I am actually more interested in them being similar. I am trying to find out what makes them differ 'so' much. 

[Alexandrov, Oleg (ARC-TI)[KBR Wyle Services, LLC]]

> I now set '--processes 4 --threads-multiprocess 4' in the call. It runs, can I assume it runs correctly if it does not throw an error?

Yes. This assumes you have 16 cores.  You may want to connect to that machine and run 'top', to see the memory and cpu usage. 

> Thank you for the clarification on the alignment methods. It seems to me that local epipolar and affine epipolar gets the same result.

They should, most of the time. Local epipolar should do better if the perspective difference or terrain relief among images is too large for a single global alignment to take care of it.

> ok, I have attached my image pair and to me they seem to have alright texture?

The image pair looks good to me.

> if I use another pair with better convergence angle, I get a lot of holes and artifacts (also attached). I guess I can use the holy DEM and project and smooth and all this, but what is more correct? A smooth solution with poor convergence angle or a 'patched' solution with a good convergence angle?

Regretfully stereo is sensitive to both convergence angle and illumination conditions. As a rule, output quality depends on input quality. 

I will suggest mapprojecting the left and right images onto that problematic DEM you get, and overlay them in stereo_gui toggling them on and off. You can see if the illumination is too different, or what the problem is in the areas you get bad results.

Here's an example of what could be a decent CTX stereo pair, perhaps, as a testcase: https://www.msss.com/science-images/test-hidden-dem-template.php. (I recall your camera was CTX, but I could be wrong.)

If you get good results for that one (you can try a clip), but bad results for your own pair, with same settings, likely that means your own stereo pair is problematic. Not sure.

[Alexandrov, Oleg (ARC-TI)[KBR Wyle Services, LLC]]

To add to the previous, you may want to look at the intersection error as output by point2dem --errorimage as well, and check if it has any large systematic or nonuniform error which may suggest one may need to use bundle adjustment. 

---

From: Alexandrov, Oleg (ARC-TI)[KBR Wyle Services, LLC] <oleg.al...@nasa.gov>
Sent: Monday, September 26, 2022 1:50 PM
To: christina Toldbo <christin...@gmail.com>; Ames Stereo Pipeline Support <ames-stereo-pi...@googlegroups.com>
Subject: Re: [EXTERNAL] Re: Squares and ripples in DEMs?

 

[christina Toldbo]

Thanks again :)

I am using Dawn images (Framing Camera) and when I look at the intersection-error I get that it is less than 20 m for the smooth pair (that has a small convergence angle) and more than 60 m everywhere if the convergence angle is 28 deg (my res is 60 m/pix). 

I took a closer look at my images and it appear that the crater slope is very dark and that the images have quite a large difference in perspective. I don't know if that indicates I should bundle adjust or just that it does a poor job at matchinf. I will try to map project and see if that changes it. Is there a recommended way? It appears there are a least three different options:

1. cam2map using ISIS

2. mapproject using ASP

3. cam2map4stereo using both ISIS and ASP?

I do not have a ground truth and also not a Datum (i use a sphere with r=265 km) 

[Oleg Alexandrov]

You can try cam2map to perhaps improve the quality of stereo. Here's an example, and note the part where the option matchmap=true is used, as we want both images to have the same rersolution.

Or, you can try other image pairs. As I recall, the Dawn FC camera is a prolific sensor. You can choose some orbit, and some consecutive images from that orbit. Or, if the convergence angle turns out to be too small, one can pick say image N and image N + 2, or so. 

Another way to make prettier terrain may be to make several stereo pairs around same location (one needs to bundle-adjust the images first) and then blend in the DEMs with dem_mosaic.

--
You received this message because you are subscribed to a topic in the Google Groups "Ames Stereo Pipeline Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ames-stereo-pipeline-support/vRjKMv1l_84/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ames-stereo-pipeline...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ames-stereo-pipeline-support/7b8a4cfd-ca1a-45a3-b548-bf2c495c5f00n%40googlegroups.com.