snaphu v2.0 and v1.4 win10 vs2017项目

####snaphu v1.4.2 对于整景哨兵数据处理太慢了####
笔记本电脑，跑了30多个小时了，疯了。

终于，还是没成功，已于2021年10月29日，07：42取消。
不知道什么原因，两个IW就可以，三个就是不行，snaphu v1.4.0直接卡死。

20211115，已将snaphu v2.0.4 从Linux 转至win10 下面的vs2017项目。
抓紧调试，理解源码，并将开源软件中的snaphu升级至2.0.4.

哭哭哭哭。

The memory footprint of snaphu v2.0 is approximately 20% smaller thanthat of v1.4.2 when both are compiled as 64 bit binaries on an Intel system. The memory footprint of snaphu v2.0 is similar to (about 2% larger than) that of v1.4.2 when both are compiled as a 32-bit binary, but v2.0 should be less constrained in terms of the input interferogram size. The memory footprint of v2.0 when compiled as a 64-bit binary is about 30% larger than when the same code (v2.0) is compiled as a 32-bit binary, although it is expected that most users will compile snaphu as a 64-bit binary nonetheless given the availability of memory on most systems.

I search and read “Notable changes in v2.0.1 since v1.4.2” completely so that you can find the most important ones in the following:

1. The new -S option invokes behavior whereby snaphu will first run in tile mode to produce an unwrapped solution then feed this unwrapped solution back into the cost calculator and optimizer as if an unwrapped phase file were read from the input. This option is equivalent to running snaphu in tile mode, then running snaphu again using the tile-mode output as an unwrapped input file using the -u option. Tile parameters must be specified when using the -S option.

2. The masking of input pixels is now supported. Typical usage of masking would be in unwrapping repeat-pass interferograms where water areas are expected to have zero correlation; a water mask can be used to exclude such areas in order to reduce the execution time.

3. The integer types of several internal variables have changed now that 64-bit systems have generally replaced 32-bit systems. The memory footprint of snaphu v2.0 is approximately 20% smaller than that of v1.4.2 when both are compiled as 64-bit binaries on an Intel system. The memory footprint of snaphu v2.0 is similar to (about 2% larger than) that of v1.4.2 when both are compiled as a 32-bit binary, but v2.0 should be less constrained in terms of the input interferogram size. The memory footprint of v2.0, when compiled as a 64-bit binary, is about 30% larger than when the same code (v2.0) is compiled as a 32-bit binary, although it is expected that most users will compile snaphu as a 64-bit binary nonetheless given the availability of memory on most systems.

4. When unwrapping in tile mode, the default behavior is now to remove temporary tile files rather than to keep them. Users can specify the new -k option on the command line or set the RMTMPTILE keyword to FALSE in a config file to keep temporary tile files.

5. A warning is now displayed if running in tile mode and the tile overlap is less than a semi-arbitrary constant warning threshold. A suggestion is displayed about increasing overlap or tile size if edge artifacts are present if the overlap is less than the tile size.

6. Connected components are now supported in tile mode. The connected components are assembled from the connected components of individual tiles and renumbered to be unique, but they will break at tile boundaries. It is possible that a component will not be fully connected in the assembled output if the component was connected only in the tile overlap area that was discarded while assembling the full output.

7. Support for Lp-norm cost functions has been added. Note, however, that congruence is still enforced, meaning that the unwrapped phase will differ from the wrapped phase by only integer numbers cycles. Therefore, the use of an L2-norm cost function is not equivalent to the least-squares phase unwrapping approaches that do not enforce congruence (as described by Ghiglia and Romero, 1996).

8. Experimental code for tree pruning has been included. This behavior is controlled by the new NMAJORPRUNE and PRUNECOSTTHRESH keywords. This code has not been well tested and users are advised to use this code with only the lowest of expectations.

I will try to read any papers they published about the mechanism of all updates and their effects on the processing results.