However, when comes the time to coregister the images, problems arise.
It is clear from the help that the stack of TOPS SLC images cannot be deramped: “The input to the operator cannot be deburst product or a stack of products such as the output of Back Geocoding operator.”
It means that a process of this type is not allowed :
In addition, computing an interferogram on a “classical” SLC stack or on a deramped SLC stack gives different results.
I’m not sure if it is intentional or not, but working on deramped TOPS SLC images alone serve no purpose in my knowledge. However, I see no way to deramp a stack of TOPS SLC images or, equivalently, stacking deramped TOPS SLC images.
If your goal is to generate interferogram, then you don’t need to perform deramp/demodulation because Backgeocoding has already done it for you. Inside Backgeocoding, deramp/demodulation is performed on the slave image before interpolation, reramp/remodulation is performed after the interpolation. You got artifacts in the output image from your second graph because you have removed the phase ramp and modulation and Backgeocoding was trying to do it again.
The deramp/demod operator is for users who have not intention to generate interferogram and just want to generate a debursted SLC image. In this case, if no deramp/demodulation is performed, artifacts will be introduced in the later on processing such as interpolation.
Dear Quentin,
I probably misunderstood your question. Regarding your last question on creating coregistered (I assume by stack you mean coregister) deramped images, I don’t think currently you can do it in SNAP 7.0. This requires modification on the Backgeocoding operator, basically (1) adding a step to deramp/demod master band and (2) skipping the step of reramp/remod slave band. Then the output of Backgeocoding is deramp/demod stack. The other way to fix this is that we can modify the deram/demod operator to undo the reramp/remod applied to slave in Backgeocoding on condition that all information needed are available in the metadata. We can discuss this issue in our next meeting with ESA to see when we can make the modifications.
I have a parallel SNAP version built in IntelliJ-IDE where I tried to modify the code to perform what you’re saying. Unfortunately the way it is written does not give much flexibility to do that (without changing a lot of lines). I will try again and let you know if it works.
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.
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.
@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)
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.