Phase Unwrapping - Githubissues

ppolabs / jlinda

jLinda - Java Library for Interferometric Data Analysis

9 stars 5 forks source link

Phase Unwrapping #13

Open pmar opened 11 years ago

pmar commented 11 years ago

Integrated minimum-norm based phase unwrapping.

pmar commented 10 years ago

Status update:

Core functionality resolved with - 61db858a455cecc3ff788fb122922d966aade3ef

NEST functionality/operator partially resolved with - 6e17db9f3de233fc6a79e251047533540f76b4db

pmar commented 10 years ago

Still open:

Full integration of unwrapper in NEST, stub and initial implementation finished, to be open-sourced and tested.
Use of more stable data-structures for sparse matrices in the core unwrapping functionality. This is a bump at the moment. While everything works for tiles of up-to 30x30 pixels, with the increase of tile size, heap space is being exhausted if no sparse matrices are being used. For example:

   dimension of Aeq (equality constraints) matrix for 30x30 input is 1521 x 6240 element matrix
   dimension of Aeq (                    ) matrix for 50x50 input is 2401 x 9800 element matrix
   dimension of Aeq (                    ) matrix for 512x512 input is 261121 x 1046528 element matrix

pmar commented 10 years ago

Discussion: Since the functionality for sparse data structure support is in development & testing, initial version is under review, considering moving milestone to 27th of August 2013.

pmar commented 10 years ago

Discussion: Also considering releasing unwrapping functionality based on Minimum Spanning Tree, as alternative to MCF/LP approach. As MST unwrapping is of L^0 norm, it is less reliable but faster, also its implementation is less memory/resources consuming.

pmar commented 10 years ago

Update: Functionality implemented with: 863f10ee, ab8a2a77, 1af1ab0 and c00de97f .

Discussion:

Initial implementation of unwrapping formulated as a LP problem, built on top of Java native (WVLPsolver)[https://github.com/WinVector/WVLPSolver] library, that turned out to be extremely slow in comparison to c-code based solvers (eg. GLPK, lp_solve, etc) - performance would scale down with the dimensions of the problem. Thus, solutions/libraries that interface C code to Java were utilized.

GLPK was selected as a primary option, because of previous and positive experiences. However problems were experienced with existing GLPK java wrappers on windows 64 platform. To resolve this, I fork the existing and outdated/not maintained libraries into a new library - LPLibs4j - that should serve as an interface and abstract layer between different solvers and functionality I need for unwrapping.