Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use masking array based on coherence #363

Open
adeane-ga opened this issue Oct 18, 2021 · 2 comments
Open

Use masking array based on coherence #363

adeane-ga opened this issue Oct 18, 2021 · 2 comments

Comments

@adeane-ga
Copy link
Contributor

adeane-ga commented Oct 18, 2021

Problem
When masking occurs based on a user supplied coherence threshold, pixels below this threshold are masked in the prepifg step by converting them to NaNs.

  • This can cause discrepancies later on in the workflow because NaNs are converted to 0.0 and the back again (during APS module).
  • 0.0 is also the no data value produced by GAMMA.
  • As 0.0 could be a valid pixel value, it means that pixels can be incorrectly masked during this type of process.

Solution

  • Perhaps masking could occur via a masked array that is calculated in prepifg but only applied where necessary.

Additional Notes
NaNs (masking) occur for at least three reasons:

  1. Input data masking (from GAMMA no data value 0.0).
  2. Coherence masking.
  3. Phase closure masking.

Would it be best to have a combined masking array that contains NaN locations for all masking reasons, or keep them separate?

Currently PyRate should use only one of phase closure and coherence in the process due to the ordering of PyRate processes (coherence masking first will disrupt the phase closure algorithm). Perhaps the coherence masking step could be applied after phase closure step?

Thought needs to be put into when and where masking occurs.

@mcgarth
Copy link
Contributor

mcgarth commented Oct 29, 2021

If the intent here is to adopt the numpy masked array functionality, I just note that that will need a big effort.

A simpler refactor that would go a long way to addressing the stated problem would be to move the application of existing masking functionality form prepifg to the last step in correct (i.e. after all other corrections have been implemented)

@adu461386118
Copy link
Contributor

adu461386118 commented Nov 4, 2021

Agree, I think this is the current strategy for mosaic operation, one of the step before mosaicing is use the averaged coherence to mask the less reliable pixels, but that is applied individually after correct step,

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants