PHR - jitter solve issues

[Marc Adams]

Hi Oleg and AMES-community,

 

I have a 22 x 19km large, mostly snow-covered PHR1B stereo-scene with 10-12 jitter oscillations from the Central Alps I would like to use to calculate snow depth. Have setup a shell-script and corresponding stereo.default (see attached) and am running the daily build 5 Aug 2025. Currently, I’m a bit stuck re the choice of parameters for the jitter solve. As per the documentation in chapter 16.39.10, after running map-project, parallel-stereo and point2dem, I copy the dense interest point matches and use them to run jitter-solve with the following settings:

 

jitter_solve "$img_left" "$img_right" "$dim_left" "$dim_right" --match-files-prefix matches/run --num-iterations 50 --max-pairwise-matches 100000 --max-initial-reprojection-error 20  --tri-weight 0.1 --tri-robust-threshold 0.1 --num-lines-per-position 500 --num-lines-per-orientation 500 --num-anchor-points 10000 --num-anchor-points-extra-lines 500 --anchor-dem "$dem_init" --anchor-weight 0.1 -o "${outputJ}"

 

I then repeat parallel-stereo, leaving out map-project, reusing the results from the previous run and resuming at the triangulation stage. Finally, I run point2dem and compare the results. Since the two mapprojected images agree very well with the hillshaded reference DEM, I skipped initial bundle adjustment. I followed the straight-forward instructions in the documentation for the PHR-example, adding those sections from the WV-example, which seemd to me to be needed to finalise the workflow.

Have tried jitter-solve with different settings for --num-lines-per-position and --num-lines-per-orientation and both the --tri-weight and the --heights-from-dem constraints. It seems the IE shows lower values in North, East and Down when using the --heights-from-dem constraint, but final_residuals_stats and triangulation_offsets are noticeably lower using the --tri-weight constraint (0.25 vs. 1 and 0.001 vs. 2-4, respectively). For dem_init I have tried using both an ALS-DGM and a blurred, gap-filled DEM output from a previous successful ASP-run, without jitter-solve, resulting in slightly more matches and lower final_residuals_stats and triangulation_offsets values when running with the latter.

My issues are:

-          When trying to gauge the effect of the jitter solve, as shown in Fig. 16.17 of the documentation, the difference image makes it look like the DEMs are shifted in North-South direction (positive values on north-facing and negative values on south-facing slopes), although I can’t seem to make out any shift when comparing the two hillshades of the DEMs with and without jitter solve (when running without jitter solve, I used the same settings as with jitter solve, leaving out the second parallel-stereo and point2dem runs)

-          The jitter in the resulting difference maps of snow depth seems to have increased rather than been reduced; the oscillations appear to me to be more pronounced after jitter solve, within the mentioned constraints and settings I tried.

 

Any advice on how I could adapt my workflow or the settings of certain parameters would be much appreciated!

Best,
Marc

[Oleg Alexandrov]

Marc,

The jitter_solve program can do less well when there are systematic issues such as snow, which are notably different in height than any of your prior DEMs.

I think the first thing to check (which appears you did) is to carefully compare the stereo DEM you get with ASP before jitter solve with your reference DEM. Hopefully there should be no horizontal differences, and vertical ones should be only due to snow depth and to jitter. I would guess such vertical differences should be on the order of 10-50 meters or so.

Then, when running jitter_solve, I think the results may be better if the --heights-from-dem option is used, but with an uncertainty, which at least early on, should be quite large, say with a value of 1000. The goal would be for this to be a very gentle constraint, to not be affected too much by the systematic issues between the stereo DEM and reference DEM.

I would guess the --num-lines-per-position and --num-lines-per-orientation could be increased, say to 1000, given that you say you have only 10-12 jitter oscillations.

It would be quite instructive to look at initial and final residuals.csv files, as these show both the distribution of triangulated interest points, and how much the reprojection error into the camera is before and after jitter optimization.

I think PHR comes with triplets of images. Maybe making use of them could improve results.

It is of great interest to us how this tool performs, and we know that the success can be site-specific. We tried this solver with areas with lots of vegetation recently, and it did well, but we had to mask the vegetation and had more than 2 images, with notable "cross-talk" between scan lines, which helps constrain the problem better.

Let us know. Feel free to respond privately as well with additional info or results.

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/dba385fc-f118-474d-91ca-a4f3dfbb6aa8n%40googlegroups.com.