ICEYE SAR - ASP matching algorithms

[Riccardo Pedrelli]

Hi all,

I'm currently working with ICEYE acquisitions, specifically trying to generate DEMs from Spotlight data. Since these are delivered with RPC data, it is possible to follow the same workflow used for UMBRA data. I currently have 31 acquisitions over the Aletsch Glacier in Switzerland.

I can confirm the difficulties associated with image matching. While my tests generally show that matching is more successful when using same-side, low-convergence angle acquisitions, I have seen some surprising matching results from opposite-orbit pairs that I can't quite wrap my head around, as the results seems quite random (lower convergence angle not always lead to a secure matching result). The algorithm typically fails at the RANSAC fitting, with plenty of matched point but no RANSAC successful fit.

I was wondering: what makes SAR images so different from optical data from a matching algorithm perspective? I would like to improve my images as much as possible before inputting them into ASP to increase the chances of a successful match, and try to find characteristics of the images to enhance in order to do that. I'm familiar with SAR, but not with photogrammetric pipelines

Thank you in advance!

Riccardo

Current Workflow: mapproject --> parallel_stereo (skipping bundle adjustment)
Mapproject performed using Copernicus DEM.
parallel_stereo variables:

• "processes": 10
• "stereo-algorithm": "asp_mgm"
• "min-num-ip": 10
• "ip-per-tile": 500
• "min-triangulation-angle": 1

ASP version: 3.6.0-alpha-2025-10-08-x86_64-Linux

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

>I was wondering: what makes SAR images so different from optical data from a matching algorithm perspective?

SAR has speckle. Sometimes the true features are not at pixel level (where it could be noise or numerical artifacts) but at much coarser resolution. SAR images can likely change in a way the human eye still finds similar but algorithms for optical data can't handle it.

It is suggested to follow the workflow here: https://stereopipeline.readthedocs.io/en/latest/examples/umbra_sar.html#handling-failure, after mapprojecting the images.

So, one can try avoiding interest point matching and RANSCAC, produce an initial disparity from DEM, and refine it with a somewhat large correlation kernel. There is also a note there about the block-matching asp_bm algorithm. This uses bigger correlation kernel size when matching left to right image, so may be more immune to noise and stuff.

Hope it works. We got good results when carefully selecting the data.

---

From: ames-stereo-pi...@googlegroups.com <ames-stereo-pi...@googlegroups.com> on behalf of Riccardo Pedrelli <riccardo...@gmail.com>
Sent: Monday, February 2, 2026 10:21 AM
To: Ames Stereo Pipeline Support <ames-stereo-pi...@googlegroups.com>
Subject: [EXTERNAL] [BULK] ICEYE SAR - ASP matching algorithms

 

CAUTION: This email originated from outside of NASA.  Please take care when clicking links or opening attachments.  Use the "Report Message" button to report suspicious messages to the NASA SOC.

--
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/64410a19-f8b3-466a-9427-706d39afd004n%40googlegroups.com.

[Riccardo Pedrelli]

Hi Oleg,

Thank you for the answer! i'll try to follow the suggested algorithm, and give an update if i can obtain improved results

>  We got good results when carefully selecting the data.

What do you mean with this? Did you selected the data just visually or there are specifc acqusition / pair parameters that always provide better results?

Thank you again,

Riccardo

[Oleg Alexandrov]

> Did you selected the data just visually or there are specifc acqusition / pair parameters that always provide better results?

As I recall images with similar incidence and azimuth angles resulted in best results. Having those close in time likely helps too. But one has to be mindful of the stereo convergence angle (as printed by stereo), as if it is too small triangulation will not work well. 

To view this discussion visit https://groups.google.com/d/msgid/ames-stereo-pipeline-support/4acbe5f1-8beb-4c29-b7d0-57aa63bf3fc9n%40googlegroups.com.

[Riccardo Pedrelli]

Thank you Oleg for the clarification!

I'd like to follow up on some issues I've encountered while using stereo_gui. when i try to visualize the .match file, sometimes i shows up as the matching did not work at all (stereo_gui left_proj.tif right_proj.tif stereo/run-L__R.match):

But when I try to process the DEM anyway, I am surprise with a "good looking" DEM:

 

I'm puzzled onthis result considering the point mathing. This is still with the old pipeline (no bigger correlation kernel)

Thank you again,

Riccardo 

[Oleg Alexandrov]

Interest point matching failed for you. To my eye the images appear to have subtle but notable differences, and then interest point matching is known to do poorly. The software ignores that and continues with the corelation.

Stereo correlation is a lot more robust as it does a multi-resolution approach, starting at a coarse scale (1/32 of original image scale). But even so the DEM you got has notable missing pieces.

There's a lot of research nowadays in AI-based feature detectors that could be more robust to various differences. Those however may need to be trained for specific setups.

In short, it is good you experiment, and try to correlate the quality of results with the geometry of the scene (so various angles for each image). Hope things work.

To view this discussion visit https://groups.google.com/d/msgid/ames-stereo-pipeline-support/d7c98947-761f-4bfb-b2f4-0435dfd2816fn%40googlegroups.com.