stripmapStack: fix reference date ignored in offset inversion

[huchangyang]

Summary

This PR fixes a bug in stripmap stack offset network inversion where the user-specified stack reference date (stackStripMap -m) was not used by invertMisreg.py or invertOffsets.py.

Changes:

• Pass the stack reference date from stackStripMap.py / Stack.py to both inversion scripts via a new -r/--reference argument
• Remove the reference-date column from the design matrix by index (refIdx) instead of always dropping the first sorted acquisition
• Insert zero-offset rows at the correct reference-date index in inversion outputs

Problem

stackStripMap.py allows selecting an arbitrary stack reference date via -m/--reference_date, and downstream steps (e.g. refineSecondaryTiming, resampleSlc) already use that date.

However, before this fix, both invertMisreg.py and invertOffsets.py always removed the first sorted date from the design matrix:

A = A[:, 1:]   # always drop column 0 (first sorted date)

and always prepended the zero-offset row at index 0:

S = np.vstack((np.zeros(...), S))

This is only correct when the reference date happens to be the first sorted acquisition. If the user selects a different reference date, the inverted per-date offsets are expressed relative to the wrong frame, causing misregistration in fine coregistration (resampleSlc reads refineSecondaryTiming/dates/<date>/misreg).

Fix

1. Stack.py / stackStripMap.py: pass stackReferenceDate to:

   • invertMisreg.py ... -r <ref>
   • invertOffsets.py ... -r <ref> (rubbersheet / dense-offset path)

2. invertMisreg.py / invertOffsets.py:

   • add -r/--reference
   • locate refIdx from the reference date in dateList
   • replace A[:,1:] with np.delete(A, refIdx, axis=1)
   • insert the zero row at refIdx in the solved time series

3. invertOffsets.py only: dateList from the internal HDF5 file uses YYYY-MM-DD HH:MM:SS, while the stack passes YYYYMMDD. A one-line format conversion is applied before matching refIdx, using the same if / elif / else structure as invertMisreg.py.

Files changed

File	Change
contrib/stack/stripmapStack/stackStripMap.py	Pass stackReferenceDate to inversion steps
contrib/stack/stripmapStack/Stack.py	Append -r in generated run commands
contrib/stack/stripmapStack/invertMisreg.py	Honor -r in design matrix and output assembly
contrib/stack/stripmapStack/invertOffsets.py	Same fix for dense-offset inversion

Test

Dataset and motivation

We tested this fix using the same ALOS-2 dataset over Kyushu, Japan described in:

Z. Yunjun et al., "Range Geolocation Accuracy of C-/L-Band SAR and its Implications for Operational Stack Coregistration," IEEE Transactions on Geoscience and Remote Sensing, vol. 60, pp. 1–19, 2022, Art no. 5227219, doi: 10.1109/TGRS.2022.3168509.

As shown in Fig. 13 of that paper, the temporal variation of range misregistration in this stack is dominated by ionospheric effects, with large delays during 2015–2016 associated with strong solar activity [Fig. 13(a)].

We chose this dataset deliberately because the acquisitions span both 2015 and 2019, i.e. epochs separated by large cumulative range offsets. This makes the test sensitive to reference-frame errors: if inversion assumes the wrong reference date, the misregistration time series is shifted to the wrong frame, and the resulting coregistration error is amplified rather than masked.

Stack configuration:

• Reference date (-m): 20190218
• Secondary dates: 20150209, 20150223, 20150810, 20150824, 20190304

stackStripMap.py -s slc/ -w . -d dem/elevation.dem -a 3 -r 3 -u snaphu -f 0.8 \
  -W ionosphere -z --nofocus -m 20190218

Before fix

With -m 20190218, the stack still inverted offsets relative to the first sorted acquisition rather than the specified reference. Two symptoms were observed:

1. Interferometric coherence: interferograms tied to the user-selected reference date showed noticeably lower coherence than pairs with long temporal baselines, consistent with residual misregistration after fine coregistration.

2. Dense-offset inversion: the inverted dense-offset time series for the designated reference date under dense_offsets/dates/ was not zero, as it should be when offsets are expressed relative to the stack reference.

After fix

Re-running the same stack with the patched code:

stackStripMap.py -s slc/ -w ./new -d dem/elevation.dem -a 3 -r 3 -u snaphu -f 0.8 \
  -W ionosphere -z --nofocus -m 20190218

Results:

• Interferogram coherence for pairs involving the chosen reference date improved and became more consistent with other pairs in the stack.
• The dense-offset solution for the reference date is now zero (within numerical precision), as expected.

Backward compatibility

• If -r is not provided, behavior is unchanged: the first sorted date is used as reference (same as before).
• When called from stackStripMap.py, -r is now always passed explicitly.