SNAPHU Unwrapping

Hi Andreas,
Can you please elaborate this overlap of 50 pixels in 10x10 while 100 in 5x5?

I am multiplying 10x10 = 100 and then 600x400 = 240000
240000/100 = 2400 ???

How can I calculate size of single tile and then set the overlap accordingly.

there is no mathematical relationship to determine a suitable overlap, but the tile number determines the tile size and the overlap should be considering the tile size.

For example, if your raster has 8500 columns and 6300 rows. If you select 10x10 tiles, each of the tiles has a size of 850 x 630 pixels. an overlap of 200 is fine.
But if your raster has 2300x1400 pixels and you select 10x10 tiles, the size of the tiles (230x140 pixels) does not allow an overlap of 200 any longer, because the overlap would be larger than the number of rows. It then makes more sense to reduce the number of tiles (e.g. 2x2 > 1150x1200) and stick withan overlap of 200 .
The overall idea behind the overlap is to seamlessly merge the unwrapped tiles so that no “chessboard pattern” is produced in the unwrapped raster.

1 Like

:roll_eyes: :disappointed_relieved:
Still not getting that 8500x6300 example. Sorry! Maybe it’s something really easy and I am not getting it. Apologies but please make it more simple for me. I don’t get that 1150x1200 part.

In the end, you want a good unwrapping result, right? So simply run it and check if it looks alright. If you see regular patterns in azimuth and range direction , change the number of tiles and adjust the overlap size. There is no ideal value to set. The only thing important is that the overlap is not larger than the tile and not too small. It should be in a reasonable relation to the tile size in azimuth and range direction.

4 Likes

Ok gave it a deep thought. So far this is what I got, Overlap has to do something with “Number of Tiles”. And it has to be less than or equal to Number of tiles. Sweet … I get it now.

  1. Find the image dimensions (Tile Size)
  2. Decide number of rows and columns e.g. any number you like and divide the entire image by it
  3. If the overlap amount is equal to or exceeds single row or column size it will show error!

Correct??

One last thing what is this Tile Threshold nd What if I set the overlap to zero, as I did in my DEM example. Just changed row and column numbers. Impact of Overlapping on Spatial Resolution of end product?

yes. SNAPHU is not very efficient in unrapping the entire raster at once, also errors add up if you do so. So especially for large rasters, it makes sense to cut the raster into smaller parts (=tiles), determined by the number of rows and colums. If you select many, the tiles will become small. But then, the overlap has to be small as well. The overlap is the area which is added to each tile (in pixels) so that adjacent tiles can be mosaiced seamlessly.

With zero overlap you often end up with jumps like this.
grafik

It is more important that you check your results and say if you like them or not. If not, then you change some parameters to fix it, not the other way round. But to do that reasonably, it is good to understand how unwrapping works in general.

Have you seen this? SNAPHU parameters
I’m not sure about the tile cost threshold to be honest, it is explained somehwere in the manual: https://web.stanford.edu/group/radar/softwareandlinks/sw/snaphu/snaphu_man1.html

2 Likes

Thank you so so much Andreas. Followed you on Twitter also. is there any impact of overlapping on spatial resolution? Again what would we do without you :slight_smile: Stay blessed man.

Luckily saw that 7 hours ago. Those parameters let me check the second link.

the input product will not change from different parameters, but surely, an inteferogram of TerraSAR-X (3m) will always look different than one of ENVISAT (30m) in general. Again, best way to find out is to try different configurations and compare the results.
I’m not actively producing content on twitter, but mostly use it to receive Earth Observation news. But I’m happy if I could help you moving forward.

1 Like

Got it. Thank you

Hello.

I wonder if anyone has any ideas on, or has previously come across, an unwrapping issue which seems to give an offset related to the wavelength of the Sentinel C-band

I am trying to produce some interferograms of a small area (5x5km). The average coherence is around 0.3, which is not ideal, but there are some large separated block of high coherence.

When I alter the Spaphu output parameters for a single pair of images from the same orbit paired 12 days apart, the product shows the general background deformation oscillating either around +0.0150, -0.0125 or -0.0400m. The differences between these figures are exactly half the wavelength of the C-band (~0.055m). I would expect the deformation to oscillate around zero outside of anomalies for such a small temporal baseline, so I guess it’s something to do with snaphu picking up the wrong cycle.

Does anyone know what is going on here?

can you please share a screenshot of the interferogram before and after unwrapping? Also where the profile of your plot is located.

1 Like

There has to be some displacement. It could be nominal but displacement is always there. Any natural -earth quake / anthropogenic events-construction on those days? Also I feel like it has to do something with the small area. How good was your back-geocoding? As you said coherence is low (0.3) lots of factors to consider. Try with another slave image etc How much pixel overlap did you gave? Try with a zero overlap. Please attach screenshot of snaphu export parameters too.

Many thanks for getting back to me and helping with this. I really appreciate it. I’ve had to reprocess with a slightly different subset boundary and this time the displacement oscillates around -0.0125 (half wavelength difference to the previous example which has the background displacement around +0.0150).

The attached shows the before and after unwrapping interferogram and the location of the profile. Naturally I would like to investigate the feature in the red circle, but absolute values would be useful.

Hi. Thank you very much for your suggestions here, I really appreciate it. This is not an earthquake area or one with a lot of construction. Back geocoding looked fine. On the above example I used 3x3 tiles with a 20 pixel overlap. I tried exporting the same subset with no overlap and result changes so that the general displacement now tracks below 0 (around -0.015) (see graph below). (Don’t worry about the change in the number of pixels - I used a profile from multiple lines going across the area on the first one)

Most of the interferograms I’ve generated show a background displacement of around -0.015 over 6 or 12 days. I even swapped the slave and master over and it still tracked around -0.015. These images stacked over 6 months it shows an displacement over somewhere around 60cm/year which from my knowledge of the area surprises me (is should be no more than a few mm in either direction).

So there is a gross error, maybe operator, maybe something to do with the area or coherence, but I can’t spot what it is.

This site is on a coastal peninsula. If I use a larger subset, there will be a lot of water in the frame. Would this matter do you think?

Thanks again.


1 Like

You can use the Band Maths to set the areas of no displacement to zero manually, as shown in this tutorial: InSAR Displacement mapping with ERS data

DInSAR is always relative and the results can have offsets, introduced by various error sources.
Especially when larger parts of the image are of low coherence, the analysis of small isolated areas (of high coherence) can be problematic.
To minimize errors, you can try to Filter out low coherence pixels before phase unwrapping

I see no problem with the magnitude of displacement of a single pair here, because it remains the same after unwrapping (one cycle in the interferogram is still one cycle after unwrapping)

1 Like

Thank you very much for the clear and very quick reply, and the links to the instructions both of which appear to address this issue. It is reassuring to know that offsets can occur and there is not necessarily a problem with this. It is also good to know that there is no obvious issue interferograms and the offset can be corrected if required.

Thanks again @ABraun for your advice on this. I really appreciate it.

2 Likes

60 cm LOS displacement is huge. Never came up against offsets in my S-1 InSAR data processing. Good to know. I hope masking low value of coherence helps.

can you maybe elaborate how you got to this estimation? How did you create the pairs and how did you combine them?

I may have made a mistake here. As the displacement product is given as metres, I took it as metres over the period between the images for that pair (usually 12 days). When I stacked the 12 images together I divided the stack by 12 and multiplied by 365, when I probably only needed to divide by 12 to get the average annual rate of displacement (as implied by the first set of instructions that you highlighted). If this is correct, then the extremes relative to the background tie in much better with what has been observed on the ground.

Filtering out low coherence before unwrapping, and the correction to the displacement, seem to work much better and give repeatable results. Thank you. Just one final question. Is it best to apply the correction to bring the general background to near zero on each image pair or the average displacement product after stacking (or does it not matter since this is a differential technique)?