Persistent Banded Error After Jitter Solve (JS) on ASTER DEMs

[Daryl Ernesto Ayala Saavedra]

Hello ASP community,

I'm seeking advice on a persistent error in my ASTER intersection error map after running jitter_solve.

The image shows the initial horizontal jitter error (left) removed, but replaced by a large, distinct banded pattern on the right side of the image (right).

What could be the cause of this new, systematic banded error on the right side of the map after JS correction? What additional parameters or methods should I investigate to fully resolve it?

BTW I tested changing --num-lines-per-position and --num-lines-per-orientation to 50 and 200, but this pattern remains.

Here is the jitter_solve command used:

jitter_solve \

  --match-files-prefix 04_initialStereo/run-disp \

  --num-lines-per-position 100 \

  --num-lines-per-orientation 100 \

  --max-initial-reprojection-error 20 \

  --max-pairwise-matches 100000 \

  --num-iterations 50 \

  --heights-from-dem 00_rawData/02_TanDEM90_R26_HF_B1.tif \

  --heights-from-dem-uncertainty 20.0 \

  --num-anchor-points 0 \

  --anchor-weight 0.0 \

  01_aster/IMAGERY_LEFT.tif \

  01_aster/IMAGERY_RIGHT.tif \

  07_ba_aligned/run-run-METADATA_LEFT.adjusted_state.json \

  07_ba_aligned/run-run-METADATA_RIGHT.adjusted_state.json \

  -o 08_jitter_solve/run

I also noticed that the final parallel_stereo run (after jitter_solve) is taking a very long time (specifically in a tile). For example in the PC that I use for these test the first parallel stereo could take 20-30 minutes but the second one could take more than one hour (even using  --prev-run-prefix)

Thanks for any insights!

[Oleg Alexandrov]

Daryl,

This is quite an unusual thing.

A few things one could try:

 - See what happens when a different stereo pair is run (for Aster there are so many of them)

- Increase   --heights-from-dem-uncertainty from 20 to 200, just to see if perhaps it was constraining to DEM too much

- Examine your DEM you constrain against and see if there's anything funny there

- Look at the final final_residuals_pointmap.csv file, and plot that one on top of the intersection error in stereo_gui. It may be instructive to see where the matches are and if they are well-distributed around that area.

My very best guess is that the internal linescan model we fit to the ASTER model did an incorrect fit for the lens distortion. But maybe the explanation is simpler than that.

If trying a different stereo pair does not change anything, and if the interest point matches are well distributed (as seen by the suggestion above), that likely means I need to revisit the code. 

In that case, if you share your testcase privately, I can take a look (if you can, but do not share as email attachment).

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/d188c9a2-15cf-4fdf-8ccf-164762986752n%40googlegroups.com.

[Oleg Alexandrov]

This turned out to be a bug on our side. The internal  lens distortion model was not good enough. I switched to radial-tangential lens distortion.

Better (and maybe faster) results are obtained by not reusing a previous run, but simply mapprojecting the images with the new cameras, and redoing stereo from scratch. I am not sure why that is so. Likely the cameras change too much in subtle ways when refitting the ASTER model as a linescan model and then reoptimizing it. 

I modified the recipe in the doc to reflect this usage, so suggesting the user does not reuse the stereo run.

Here's the final residuals pointmap.csv file before and after the fix, once the jitter is solved for. The artifact goes away on the right.

Here's the point2dem triangulation error (intersection error) before and after the fix:.

Here's the diff from the stereo DEM and the reference TanDEM DEM. The vertical range is -20 to 20 meters.

I must say this difference is way too big. At the center bottom, it looks like that is due to the changed volume of ice or something. But I don't think that explains it all. Maybe there is misalignment too, though it can't be easily seen visually. 

Note that we added a new pc_align algorithm called Nuth that may be worth experimenting with. 

Maybe one can try the jitter solver in an area where the ground is not as steep or did not change as much as well.

The fix will be in build 2025-10-08 within 24 hours, at https://github.com/NeoGeographyToolkit/StereoPipeline/releases. 

Note that we have a section on limitations of this jitter solving program (https://stereopipeline.readthedocs.io/en/latest/tools/jitter_solve.html#limitations). In your case, if there are multiple overlapping similar images, maybe jiter could be solved jointly, resulting in a more reliable terrain.

Thank you for the report.