isce-framework
Pycuampcor v2
PyCuAmpcor Version 2 introduces a new workflow inspired by GrIMP/SpeckleSource, in addition to the original ROIPAC/ampcor workflow. Below is an overview of the new workflow and additional improvements:
Key Features of the New GrIMP/SpeckleSource Workflow:
- Starts with an anti-aliasing oversampled secondary chip over the entire search range.
- Adds extra margins to facilitate correlation surface extraction.
- Offers optional double-precision computations (also extended to the ROIPAC/ampcor workflow for consistency).
The GrIMP/SpeckleSource workflow may be slower than ROIPAC/ampcor due to increased computational demands. However, it may improve accuracy in scenarios with low signal-to-noise ratio (SNR). More details on the workflows and how to choose can be found at contrib/PyCuAmpcor/README.md.
Other Improvements
- Introduced an option to fix the starting pixel location, which is ideal for comparing results from different window sizes.
- Added an example script for plotting the offset field, making it easier for users to visualize results.
- Included correlation peak values in the output, alongside SNR and covariance, providing additional accuracy measures.
- Resolved a memory deallocation issue that occurred when the run procedure was called repeatedly within a single script.
Thank you @lijun99 for this extensive PR. Based on our offline discussions I'm aware of most of developments in this PR. However, for clarity and to help the user community following this repository would you please update the description of the PR and provide some explanation in few bullets summarizing the changes that comes in this PR.
@lijun99 Thank you for adding the PR description. I agree with @vbrancat 's points about the GRIMP/ROIPAC terminology. Perhaps the correct thing is to be just clear about the changes made to the PyCuAmpcor. Main reason is that the base of GRIMP was also original JPL's roipac ampcor. The fact that upfront upsampling has been dropped at some point in some version of it for computational efficiency while kept in other versions such as the one in GRIMP may be just a source of confusion.
We see that one big change contributing to the big PR is the functionality to build the code with both single/double precision. Since our tests have not demonstrated a meaningful difference for the offsets results with the two builds, we are a bit hesitant if we should go that way. Or at least we are not sure if the implementation approach for adding double precision is the most efficient way. Are you open to:
1- remove double precision build from this PR. We expect that would significantly reduce the number of lines of codes in this PR 2- If you definitely want to add double precision and have a good reason for it, let's discuss if templating the code would be a better approach and have a separate PR in future.
I have merged all the pycuampcor updates to a separate repo, which can be embedded as a submodule in isce2/isce3: here is an example. @rtburns-jpl , please let me know whether this is what you prefer. ( I have renamed the module in lower cases, per the conda requirement).