[Help]: Correlation vs. StdDev exclusion

[SteffanDavies]

In you examples you use interferogram correlation or unwrapped phase standard deviation as criteria for selecting best pairs. However you don't explain which method is more robust or under which circumstances one should be preferred over the other. Using correlation we have the advantage of filtering interferograms before the unwrapping stage, saving a lot of time. Using stddev however, wastes time unwrapping pairs that will be excluded later on. Actually, in one of your example notebooks, you end up unwrapping pairs and only selecting based on correlation later, which means you wasted time unwrapping bad pairs.

Could you explain what is the reasoning behind selecting either corr or stddev estimate quality?

[AlexeyPechnikov]

The correlation-based approach is the most efficient in terms of processing and is theoretically sound. However, in practice, we sometimes encounter inconsistent estimations using the best correlation pairs and those with the least deviation, due to issues with SNAPHU unwrapping. In such cases, high deviation implies low correlation plus significant unwrapping errors, making it easier to use despite being computationally intensive. Additionally, deviation helps identify scenarios where the entire area is split into a set of inconsistent, disconnected unwrapped components, resulting in large deviations even with high correlation. As such, deviation estimation is primarily aimed at addressing SNAPHU-related issues. In practice, for small areas where unwrapping is quick, the deviation-based approach can be utilized. However, for cases that require excessive time, the correlation-based method becomes necessary. Should I develop a special 2D/3D unwrapper superior to SNAPHU, we might always use correlation estimation.

[SteffanDavies]

Thank you for explaining. I have been using correlation based approach due to very large stack size (1000-4000 interferograms) because unwrapping becomes unreasonably expensive, and large enough areas tend to cause disconnected components anyway unless a very large filter wavelength is used.

I think you will find it difficult to create a fast enough Snaphu alternative without using python wrappers to C code.

[AlexeyPechnikov]

That's correct, and it's the preferred method. However, for technical reasons, I also provide examples based on deviation. You might be surprised to learn that an alternative prototype for SNAPHU requires only about 100 lines of code, utilizing well-known and fast scientific libraries. The most time-consuming part of this code involves transforming a raster into a graph. The Python Numba library can significantly accelerate this process, as demonstrated in PSI unwrapping within PyGMTSAR.

There are several interesting ideas, such as parallelizing the unwrapping of large rasters, performing 3D unwrapping, and more, all of which require thorough investigation to be implemented.

[teagamrs]

Great discussion guys, I've noted this two scenarios in Alexey's notebooks too. I'm using correlation for time saving but checking later the stddevs.