Hi,
There has been lots of suggestions and requests of improvement regarding the preparation to unwrap phase with SNAPHU.
I am still extremely confused by what SNAP intends to do compared to what is specified in SNAPHU and other wrappers of SNAPHU.
The first improvement is to be able to select a band ourselves for the phase and the coherence. I cannot understand why if we filter the bands we cannot export, it makes little sense. I have seen a few tricks on the forum but I have never managed to perform them. Why is this so stringent and inconvenient?
It is my understanding that SNAPHU likes complex data which are, if I understand well, the i (real) and q (imaginary) extracted from coresgistered images. Why would we provide an angle only? It is very convenient to work directly on i because you can make an expression such as i=0 above water and if coherence <0.2. Notice that SNAPHU uses the coherence layer but we don’t know how through the configuration file.
SNAPHU takes masks which would greatly help unwrapping but we don’t know how to set it up in the current design.
My current application is for S1 SLC deformation analysis. I see that these improvements are being requested since many years. Would it be possible to have some kind of synopsis to know better what could be done and eventually check why this is not really functioning as it should?
Here is what I am facing which makes no sense (it was flagged in other posts)
Filtered or unfiltered even in high coherence areas, the unwrapped result is flat with some “islands” that do not correspond to any of the input amplitude, coherence or resulting phase
You will be waiting forever, as you already know. Try open source PyGMTSAR (Python InSAR) with interactive live examples at https://insar.dev
PyGMTSAR is a complete InSAR software performing all the tasks from Sentinel-1 SLC scenes and bursts plus orbits and DEM downloading and up to SBAS and PSI processing and 3D visualization. It provides correlation weighted SNAPHU unwrapping, SNAPHU NODATA, and far beyond.
P.S. ESA staff ban for open source InSAR software references so probably I will not be able to answer you here. You would find PyGMTSAR community on GitHub and LinkedIn.
Thanks,
I will give it a go when I have a bit of headspace. Actually the issue I describe and other describes is a bug in SNAP. I have described it but it has not been flagged as such. The ensemble of angles in Snap is exported as a zero-phase interferogram whereas SNAPHU expects a minimum-phase interferogram. It is a pretty big mistake and I am certain it has been in the software for a while as I have seen similar results to mine on several posts. Anyway, at the moment I script to correct this and it kind of works.
Cheers,
I’m not sure what you mean here, but the SNAPHU mask is not a silver bullet. In cases where your valid area is disconnected into separate areas by the mask, the results may not be valid. A more robust approach is to apply nearest neighbor interpolation to fill phase gaps and only mask out the pixels outside of the work area. Of course, it’s still possible to use the SNAPHU connected components map to check for disconnected areas and attempt to merge them unwrapped, but these can be inconsistent, and accurate merging may not be possible.
Overall, it’s better to use sparse pixels graph-based phase unwrapping. I’ve shared the branch-cut realization here: pygmtsar/todo/branch_cut.ipynb at pygmtsar2 · AlexeyPechnikov/pygmtsar · GitHub, though it is not integrated into PyGMTSAR for now. The branch-cut approach works for wrapped phases, which means we need to define the proper connections (edges) between sparse pixels. In contrast, integer linear programming to detect phase jumps (and compute the unwrapped phase accordingly) can operate on phase differences and even wrapped phase differences, allowing you to fill missing values with zeroes (instead of neighbor interpolation for straightforward phase value unwrapping) or omit connections corresponding to missing values for sparse values unwrapping. I’ve implemented all three realizations (branch-cut for wrapped phases like SNAPHU does and integer programming approaches for phase differences and wrapped phase differences) and can share them if you want to try pure Python unwrapping. It seems promising to provide all the unwrapping approaches in a single Python package to cover various use cases, but it is a time-consuming task. If you are interested, feel free to try my implementations without waiting for them to be production-ready.
very simply if you read the post SNAP works in [-pi,pi[ and snaphu in [0, 2pi[ but when you export to snaphu in SNAP you get an image in [pi,-pi[ that cannot be interpreted in snaphu and generate a very large number of artefact. This has nothing to do with connectivity which I agree could be much better treated.
Wow, you are still suffering with such crazy things. Maybe do you even downloading the complete Sentinel-1 SLC scenes to unpack them locally? When you will need precise SBAS and PSI analyses PyGMTSAR is here to help you, and without any issues with SLC individual bursts downloading and stitching, area of interest cropping (even covering multiple subswaths), unwrapping, SBAS and PSI processing and 3D interactive visualization in a single Python library.
@MBG as I said, I will have a look when I have the headspace… I think that correcting a major software suite is also important even tho it has some defaults, it has also a lot of very good things. Also when people ask you how you did it, generally they want to refer to the software and libraries are unfortunately not yet considered references. I have had the dire experience recently having coded probably one of the best model available open-source in a domain and industrials just don’t want to test it. Thanks for your development and as said, I will consider it asap (which might be in a long time).
Best
Windows OS is based on libraries too, and there is no problem referencing it. But how do you refer SNAP for your InSAR processing when it is completely impossible to perform InSAR processing in SNAP? SNAP cannot perform InSAR analysis like SBAS and PSI. Actually, it is only parser of different satellites data formats plus phase difference calculator which we can write in a few hours: Write a Sentinel-1 InSAR Processor in One Evening? and an image-aligning tool that can be completed in another evening as well: pygmtsar/todo/PRM.robust_trend2d.ipynb at pygmtsar2 · AlexeyPechnikov/pygmtsar · GitHub (this includes my own robust regression implementation, which surprisingly outperforms the NumPy and SciPy alternatives, so I use it).
When you will need precise SBAS and PSI analyses PyGMTSAR is here to help you, and without any issues with SLC individual bursts downloading and stitching, area of interest cropping (even covering multiple subswaths), unwrapping, SBAS and PSI processing and 3D interactive visualization in a single Python library.