PyRate
PyRate copied to clipboard
Use masking array based on coherence
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:
- Input data masking (from GAMMA no data value 0.0).
- Coherence masking.
- 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.
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)
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,