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.
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?
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)
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.
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.
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)?
Thanks for the reply. I’m glad if uncovered something useful. As stated in the reply above the estimation was probably a mistake. Masking appears to be giving repeatable unwrapping results for this image pair at least (when adjusting the export parameters). It is good to know that the offset doesn’t mean that a part of the process had necessarily failed.
@ABraun I have a question too.
Suppose we’re not studying displacement rather CCD “coherence change detection”. Do you think in time-series analysis of vegetation there’s a need of masking out low coherence values. As you said “errors arises because of many reasons” how are we going to be sure that this value of coherence is not ambiguous?
No, CCD makes use of low coherence. But as in every radar analysis, three ability to detect small targets depends on the spatial resolution and the degree of noise. The more images in the time series the higher is the chance to identity random outliers.
Pardon me, I couldn’t fully understand this figure. This is the raster size of the interferogram,
I have set the values of rows and column overlap to 200 yet I received and error message says the overlap is too little. I may double the size of overlap as you have mentioned before and see if it makes a difference.
yes, if the error message states the overlap is too small, you should increase it. But 24000 rows is quite heavy, to you really need them all? Maybe multi-looking the interferogram before unwrapping can speed it up a bit as well.
The Interferogram raster consists of only three bursts, I didn’t think it was heavy but it may take too long to process each burst individually.
According to your statement, aside from taking too long to unwrap so many rows, would that cause unwanted unwrapping errors? Hopefully not, because the interograms themselves don’t display a pronounced fringe pattern but I was told to continue to unwrapping step to see if there has been a surface motion detected at all.
Multi looking can cancel out minor phase noise, but if the interferogram quality is bad in general, neither filtering nor multi looking will be able to improve it. So simply continuing with the processing amr hoping for better results to emerge makes little sense to me.
These are a few examples of how most if not all the interferograms in this area look like. I have included one more or one less burst for each interferogram based on the earthquake’s epicenter location just to test and check how the results would visually differ.
Some interferograms show no pattern at all, some will show pattern similar to the topography others display a very irregular pattern.
I know that may not make sense but I am trying to figure out whether the processing is faulty, or the past earthquakes shockwaves themselves had caused little to no surface deformation, so the radar interferometric processing won’t be useful to apply to this study area
