Correlation issue after adding bundle adjust to process PHR-imagery

[Marc Adams]

Hi folks,

I'm new to ASP and am trying to process a snow-covered stereo PHR-scene, acquired in April 2024 over the Austrian Alps. Have setup a basic shell-script (see attached), which has worked well this far. Recently however, I added a bundle adjust command and am now having some issues getting the script to run through - processing keeps tripping up during the correlation step after 6-7h, with this error:  

Traceback (most recent call last): File "/mnt/SSD_4TBmp/PHR/software/StereoPipeline-3.6.0-alpha-2025-04-29-x86_64-Linux/libexec/parallel_stereo", line 1198, in <module>

build_vrt('stereo_corr', opt, args, settings, georef, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

File "/mnt/SSD_4TBmp/PHR/software/StereoPipeline-3.6.0-alpha-2025-04-29-x86_64-Linux/libexec/parallel_stereo", line 310, in build_vrt raise Exception('No tiles were generated.') Exception: No tiles were generated.

I have tried a range of different settings:

- Changing the stereo algorithm has no effect - correlation fails on the same tile every time

- Changing the tile-size also has no effect, processing still aborts with same error after 6-7h

- When changing corr-memory-limit, processing fails on a different tile, but after a similar amout of time

- When running with corr-seed-mode 2, I get this error:

ERROR: For --corr-seed-mode 2, the value of disparity-estimation-dem-error must be positive. Traceback (most recent call last): File "/mnt/SSD_4TBmp/PHR/software/StereoPipeline-3.6.0-alpha-2025-04-29-x86_64-Linux/libexec/parallel_stereo", line 1030, in <module> settings =

run_and_parse_output("stereo_parse", args, sep, opt.verbose) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

File "/mnt/SSD_4TBmp/PHR/software/StereoPipeline-3.6.0-alpha-2025-04-29-x86_64-Linux/libexec/asp_system_utils.py", line 319, in run_and_parse_output          raise Exception('Failed executing: ' + " ".join(call)) Exception: Failed executing: /mnt/SSD_4TBmp/PHR/software/StereoPipeline-3.6.0-alpha-2025-04-29-x86_64-Linux/libexec/stereo_parse -t pleiadesmappleiades --b>

Am starting to run out of ideas, what else I could try, so any advice on how this issue could be resolved would be very much appreciated!

Best,

Marc

[Oleg Alexandrov]

To start with the easy issue first, for --corr-seed-mode 2, one needs to indeed set --disparity-estimation-dem-error. There is an example here: https://stereopipeline.readthedocs.io/en/latest/correlation.html#d-sub-dem

I looked at your script. It looks correct. You can try to look at what changed when things broke. 

For example, how do mapprojected images look without bundle adjustment, and then with bundle adjustment?

You can also try debugging on a small area, so you don't have to wait for 7 hours. So, choose a DEM to mapproject onto which is say 2 km by 2 km. Run the process the way which works. Run the other way. See what is different in logs and intermediate data (such as number of interest point matches, L.tif, R.tif, correlation search range, etc).

--
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/f99613c7-4e67-4c38-b990-1ed6af941db5n%40googlegroups.com.

[Marc Adams]

Excellent, thanks for your swift reply, Oleg!

Setting --disparity-estimation-dem-error got rid of the first issue, but correlation with BA still failed with corr-seed-mode 2.

Mapprojected images look very similar with and without BA. However, looking through the log-files while debugging, my hefty 'Distance between camera centers' of 293,416 meters caught my eye. This is the same value to the meter with and without BA. Without BA, the script completes and returns plausible snow depth maps, but might the long distance value be something that could trip up the BA?
I compared other interim results with and without BA and cannot seem to find anything major in the way of difference between the two. However, it looks like with BA, the correlation step finishes, but fails to blend the tiles. When i re-run parallel_stereo with the --entry-point 2 option, commenting the BA and map-projection steps, this error occurs:

ERROR: Error parsing folder string: .
Command exited with non-zero status 1

Also: I have tried different UTM-projected seed-DEMs - originally I used a DEM from an ALS-campaign of the area, but as per your suggestions in a related post, have switched to blurring a DEM output from a successful ASP-run, which resulted in less matching-gaps. Could the choice of DEM (source, resolution, etc.) trip up BA?
I have added my std-out logs from the last two runs of an image subset.

[Oleg Alexandrov]

>but might the long distance value be something that could trip up the BA?

It should not. What you have here, 293,416 meters between cameras is very normal given that the cameras are usually 500 - 600 km above the surface. This makes a triangle with the tip towards the earth having an angle of maybe 30 degrees (+/10 degrees). As it should be.

I compared other interim results with and without BA and cannot seem to find anything major in the way of difference between the two. However, it looks like with BA, the correlation step finishes, but fails to blend the tiles. When i re-run parallel_stereo with the --entry-point 2 option, commenting the BA and map-projection steps, this error occurs:

ERROR: Error parsing folder string: .
Command exited with non-zero status 1

This is not related to bundle adjustment, even though it shows up that way. 

>Could the choice of DEM (source, resolution, etc.) trip up BA?

No. It would just produce strange answers, but it would not fail with that error.

This looks strange: --bundle-adjust-prefix ./PHR_1B_2024-04-06-10-13_Run41-4096_2048_2048_2048/4096_2048_2048_2048

It is as if parallel_stereo's own convention got copied over to bundle adjustment. Normally it should be something like: --bundle-adjust-prefix ba/run

If your error is reproducible, say with very small mapprojected clips, and you can share privately the data (the clips, bundle adjust prefix, dem, and precise command for stereo), I can take a look. This logic did not change for many years and it is likely some quirk that results in problems.

 

To view this discussion visit https://groups.google.com/d/msgid/ames-stereo-pipeline-support/c9b3d313-454a-487b-ba31-b31860b6f5b8n%40googlegroups.com.

[Oleg Alexandrov]

After looking at this more, this seems to be a bug on our side. 

The parallel_stereo program was confused that --bundle-adjust-prefix and the stereo prefix were the same. I put a fix.

What you can do in your script for now is to not use ${outputPrefixFine} also for bundle adjustment, but to change to some other string.