[Help]: Obvious stitching boundaries appearing in the velocity map when processing a large-area dataset

[bunnyandcat]

Hello, thank you very much for developing and maintaining pygmtsar!

I encountered an issue when using pygmtsar to process a large-area InSAR dataset.
The generated velocity map shows obvious boundary artifacts between different regions, which look like a “stitching effect.”

However, when I process a smaller-area region, this stitching does not appear.

Below is an example of the velocity map (the processed area spans approximately 0.6° × 0.6° in latitude and longitude):

My questions are:

1.What causes this kind of stitching or boundary artifact in pygmtsar’s velocity map?

2.How can I eliminate or reduce this stitching effect?

Environment:

Ubuntu 22.04

PyGMTSAR version: 2025.4.8.post1

[AlexeyPechnikov]

The question is when the stitching effect occurs: right on interferograms or only after unwrapping? There are many places when stitching is used or can be used: stitching subswaths, tiled unwrapping, etc.

[bunnyandcat]

It appears during the detrending step after phase unwrapping. I also found that it is not a burst stitching boundary; rather, the seam-like artifact is introduced by the detrending process itself, because the same phenomenon is also present during detrending when processing a single burst.
Figure 1 shows the unwrapped phase, Figure 2 shows the phase during detrending, Figure 3 shows the phase after detrending, and Figure 4 shows the detrended phase of a single burst.

[SteffanDavies]

It appears during the detrending step after phase unwrapping. I also found that it is not a burst stitching boundary; rather, the seam-like artifact is introduced by the detrending process itself, because the same phenomenon is also present during detrending when processing a single burst.
Figure 1 shows the unwrapped phase, Figure 2 shows the phase during detrending, Figure 3 shows the phase after detrending, and Figure 4 shows the detrended phase of a single burst.

This is probably related to the chunk size. If you want a seamless detrend you have to increase the chunk size to cover your entire dataset. However, at a certain point, you will run into memory issues.

[AlexeyPechnikov]

Right, that’s the Dask chunking. The safe way is to reduce detrending resolution because we don’t need high resolution to fit. Detected trend phase can be upscaled to the original phase grid. Also, we can change chunk size if available memory is sufficient (less Dask workers helps).