Output has error after SNAPHU Unwrapping


I am currently performing DInSAR for understanding displacement, but I seem to be bothered with an error. When I check the coherence and phase images, things seem to be fine. Was wondering if someone can help me get over this, somehow?!?

The last part of this image shows the output of unwrapping after converting it to displacement (using ‘Phase to displacement’ function). I am unable to understand why there is a sudden change in the displacement values as highlighted in the picture with a black dashed line.

I performed unwrapping on Ubuntu using SNAPHU
1 X 1 tile (not the default 10x10 tiles)
4 cores

What could be causing the error? and how can I overcome the problem? Coherence and Phase bands seem to be alright.


Do you have the same problem, when you performed the default?

Did you apply ESD, after backgeocoding?

Which DEM did you use in the corre. step?

What is the length of the PB?

Could you please share the unwrapped phase,

This is the unwrapped phase.

  • Regarding using the default tiles (10x10), I would have good similar result.
  • I did apply ESD after geocoding the image.
  • SRTM DEM 3 Sec DEM was used
  • PB?? Couldn’t understand the abbreviation.

Is ti applied on the same study area?

What appears in your screenshot it the phase jump, Before playing with the parameter of the ESD, I’d suggest using the SRTM 1sec instead of the SRTM 3sec,

This refers to the Perpendicular Baseline,

Also according to your previous screenshot this jump phase didn’t appear in your wrapped phase.

If I am right - if it was a phase jump it should have been along the phase fringes, right? But here, it looks like its sharply along a straight vertical line.

Exactly. That’s why I am not worried about the coregistration/ESD/Phase generation, but only about phase unwrapping. Looking at wrapped and unwrapped phase images, it is understood that something went wrong while unwrapping?

I tried to repeat everything with exactly same settings, and the results were same. I will surely try what you said, but will that help? I’m a bit doubtful.

Perpendicular Baseline - 4.35m

I think it’s not always the case,

What’s the goal of same setting, nothing could be gained,

This leads us back to this comment,

Also an important thing, this might be comeback to the phase discontinuity,

@anirudhavm For me the unwrapped phase looks fine. In order to get better idea of the results you could export it to Google Earth to have the scale i.e. legend as well .

SRTM 3 arcsec could be too coarse if you work in mountain area try with 1 arcsec or even better with local DEM

the sharp edges in the unwrapped interferogram are related to the tiling of the full image during the unwrapping. Try another colum and row number and also change the overlap between the tiles. Test a bit to find the setting which results in less edges.

1 Like

@ABraun I have used 1X1 (row X column) tile for unwrapping. Even then? Because in this case the whole image is unwrapped as a single tile. 1 x 1 tile took 37 hours for the entire scene to unwrap.

Let me try with other combinations.

That is strange indeed, and you are right that it should not happen then. Can you please have a look in the temporary tiles folder (same directory) and see how many files are in there?
(If you restarted the process, they might be overwritten in the meanwhile)

Another thing to try is to select SMOOTH instead of TOPO.

If I remember correctly 1x1 is not a good option since it tries to resolve very ill posed problem.
Below is excerpt from the SNAP help page.

Two-dimensional phase unwrapping is the process of recovering unambiguous phase data from a 2-D array of phase values known only modulo 2pi rad. SNAPHU is an implementation of the Statistical-cost, Network-flow Algorithm for Phase Unwrapping proposed by Chen and Zebker. This algorithm poses phase unwrapping as a maximum a posteriori probability (MAP) estimation problem, the objective of which is to compute the most likely unwrapped solution given the observable input data. Because the statistics relating the input data to the solution depend on the measured quantity, SNAPHU incorporates three built-in statistical models, for topography data, deformation data, and smooth generic data. The posed optimization problem is solved approximately with use of network-flow techniques. As SNAPHU uses an iterative optimization procedure, its execution time depends on the difficulty of the interferogram

The suggestion from @ABraun to use SMOOTH is an option, but my positive experience is with SMOOTH/MST combination.

1 Like

I don’t see a temporary tiles folder in the same directory. I remember seeing it once long ago, but not now. I have also tried to make hidden files visible, yet no luck. Is it being stored anywhere else? Or may be getting deleted (automatically) after the process is complete.

I tried unwrapping using SMOOTH and MST operator instead of DEFO and MCF. But no luck here as well. The results are similar. What I see on the other hand is, if I unwrap after multilooking it gives better results in some cases (not all). But, is it the right thing to do?

Hi. I am sorry, but I didn’t really understand why you mention that using a 1x1 tile combination for unwrapping isn’t a good option. Unwrapping it as a single tile usually returns the best possible results - as the whole scene is used as a single component unlike other cases where the scene is clipped, unwrapped independently and then patched together.

@anirudhavm My point was that using 1x1 is hard to solve for large image. My positive experience with 1x1 is with subset of one swat. Otherwise a lot of memory is used (personal opinion). You may also take a look at this video - https://www.youtube.com/watch?v=w6ilV74r2RQ

That’s exactly what I did mention in my previous post,

One solution of avoiding phase discontinuety is, increase the memory, or/and subset the AOI to small tile.

I personally do a sub-setting in order to speed up the process.

dear anirudhavm;
I have the same problem. did you find the solution? How did you fix it?

Try ensuring all your input datasets (also the DEM should be in WGS84) are in WGS84 format.

I didn’t end up with a solution at that time but later found that this could potentially have been the problem.

thank you. I used auto download item for DEM.