Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Systematic burst-to-burst phase offsets in S1C x S1D interferograms

Open
  • Is something wrong?
#375 3 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Active
Tech stack
python
Domain
data

Research direction

Start by reproducing the burst-to-burst phase offsets with the Croatia S1C/S1D test dataset and the COMPASS-generated CSLCs, comparing same-sensor and cross-sensor interferograms. Trace the COMPASS and ISCE3 processing path from CSLC formation through burst interferogram mosaicking; done means cross-sensor bursts stitch without systematic phase jumps or manual offsets.

Written by the indexing model from the issue text.

Description

Hi,

As my first experiment with ISCE3, I tried processing 2026 Sentinel-1 data over a Mongolian permafrost area (burst ID t077_164009_iw1 to t077_164016_iw1). This particular area is imaged by S1-C and since April 2026 also S1D. I followed the stack processing tutorial from this year's Earthscope course, and managed to geocode/coregister the data with COMPASS, form the per-burst interferograms and stitch them. I found no issue with InSAR pairs where both scenes were acquired by the same sensor, S1C or S1D.

However, I am seeing systematic phase jumps between adjacent bursts when forming S1CxS1D interferograms from COMPASS-generated CSLCs. When adjacent burst IFGs are mosaicked, each burst has an approximately constant phase offset relative to its neighbour. I reproduced this both over Mongolia, forming several S1CxS1D IFGs, and also using the exact Croatia S1C/S1D test dataset from isce-framework/s1-reader#151 which introduces S1D support, but shows only one burst as the result. (reference S1C_IW_SLC__1SDV_20260416T164125_20260416T164152_007244_00EAE8_2D6E, secondary S1D_IW_SLC__1SDV_20260417T164135_20260417T164202_002389_003E83_9EFF)

The effect seems to be systematic too. Using pixels with coherence >0.6, the burst overlap phase difference over Croatia is approximately 1.65 rad in IW1, 1.40 rad in IW2, and 1.45 rad in IW3, with very little variation from one burst boundary to the next. The Mongolian stack showed the same behaviour (~1.50 rad per boundary). I tried to apply the measured constant phase offset to the burst IFGs before stitching them together, and the discontinuities disappeared.

I am on Python 3.12.10, GDAL 3.10.3, COMPASS 0.5.7, and s1reader 0.2.6. I tried both the newest ISCE3 0.25.8, and ISCE3 0.24.4 reported in isce-framework/s1-reader#151, and got the same results. Here's an example from IW3:

t073_154920_iw3.int <-> t073_154921_iw3.int: N pixels 1,113,732, phase=+1.4519 rad
t073_154921_iw3.int <-> t073_154922_iw3.int: N pixels 734,984, phase=+1.4707 rad
t073_154922_iw3.int <-> t073_154923_iw3.int: N pixels 993,869, phase=+1.4762 rad
t073_154923_iw3.int <-> t073_154924_iw3.int: N pixels 1,094,283, phase=+1.4357 rad
t073_154924_iw3.int <-> t073_154925_iw3.int: N pixels 909,584, phase=+1.4257 rad
t073_154925_iw3.int <-> t073_154926_iw3.int: N pixels 1,030,350, phase=+1.4178 rad
t073_154926_iw3.int <-> t073_154927_iw3.int: N pixels 940,087, phase=+1.4467 rad
t073_154927_iw3.int <-> t073_154928_iw3.int: N pixels 1,214,783, phase=+1.4403 rad

Could someone who knows more about the different components look into this, or tell me if I possibly did something wrong? Right now, I could "fix" my stack by applying these constant offsets to the affected IFGs, but I don't know how much this issue actually affects the underlying data quality, so I'd like to have this fixed upstream rather than in postprocessing. Thanks!

Jakub

Image Image Image
Dominant language
Python
Stars
250
Forks
92
Avg merge
1d 1h
Merged PRs (30d)
16

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from isce-framework/isce3

All issues in isce-framework/isce3

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.