I’m coming back to you after some new results. I “managed” to coregister the deramped TOPS images.
I debursted the deramped images so that I can perform more common coregistration. Coregistration gave me a java_null_pointer_exception. Then I tried the DEM-Assisted Coregistration. It worked quite well. To be sure the phase information is correct, I performed interferograms using my stack of deramped TOPS SLC images. The results are pretty I guess.
I compared this interferogram with the one computed using the “classical” Sentinel-1 chain in SNAP (S1 TOPS Coregistration), meaning on reramped TOPS SLC images.
When I look at the difference between interferograms (mod 2 \pi), there’s for each burst a residual phase pattern. This phase pattern can be important.
What is your use-case exacly Quentin?
I’m sending you a private message.
A ticket has been created to capture the issue: https://senbox.atlassian.net/browse/SITBX-640
Jun, can we extend the use-case so that deramping co-registered stacks becomes possible?
Yes, we can modify the Backgeocoding operator to make it output deramp/demod stacks
Does this means that classical Insar processing chain in SNAP introduces linear phase ramp in random direction for every burst, or could there be another explanation?
I wish I knew. Because my area is moving fast in azimuthal direction, other biases related to the TOPSAR acquisition mode does not allow me to isolate the problem.
I believe the ramp phase has been cancelled out during the calculation of the interferogram
Just a notification to say that it now works like a charm on SNAP 7.0 public release. Thanks for the hard work
EDIT : SORRY BUT STILL NOT WORKING. Still azimuthal phase bias :
@qglaude I follow this topic from the beginning and would be interested in what you are trying to do with these deramped stacks. So feel free to keep us updated in here about the outcomes
(of course it is understandable if you want to keep it secret until you have officially published something with it)
Right to the point. I’d like to be transparent but not possible until stuffs are at least submitted
Don’t feel pushed - as it is your work you have to make sure that you are the main benefitor in the first place. You can also simply post a link to the publication once it is available.
The Backgeocoding operator has been modified to add an option to output deram/demod master/slave bands. You can give it a try.
Thank you for taking the time to answer me.
I’m using the official release of SNAP (7.0.0). I see no available updates.
Using this version, the back geocoding module looks like this :
In appearance, nothing changed compared to SNAP version 6. Should it be an additional option ? Did I do something wrong?
The results are, the real and imaginary parts of the master and slave image, with an additional band related to the deramped and demodulated phase of the slave image. Note that the master and slave images are NOT deramped.
Using @nuno.miranda’s document (equ. 15), I am able to deramp the slave image. But I notice this phase band can also deramp the master images.
For information, I performed exactly what was done here : Deramping TOPSAR SLC data. In the topic, I notice that the deramp was not working for the master. But now with SNAP 7 it seems it works
The modified code has been checked in to GitHub. You can get it from there and build your snap again.
Meaning I have to re-build SNAP from sources if I understand well ?
Is the output of deramp and demod phase required for interferometric generation
No, for interferogram generation you can use the output of backgeocoding directly