I’ve been trying to coregister an Envisat-stack using the S1TBX, and in parallel I have processed it using DORIS. The frames are above dessert areas, so there is almost no decorrelation. Should be an easy coregistration.
The DORIS processing results show very nice interferograms, but the same interferograms made with the s1tbx are much less. It seems to be a coregistration issue, as there are a lot of orbital fringes. The issues are related to the problems reported in an earlier post.
I have tried different processing graphs. But with or without DEM assist, with or without orbit file, with or without createStack, It does not seem to make a difference. Therefore I think the problem is in the cross-correlation or wrap operator. In the figure below I’ve added a comparison.
If necessary for debugging, we can provide you with a subset of the data.
I’ve tried with some ENVISAT with doris orbits using the Coregistration without any issue.
Could you provide data files so I could look into this further?
Applied Doris precise orbits
Applied Coregistration with 20k gcp, 0.5 rms threshold
Applied Goldstein filter and terrain correction on the phase.
I see some vertical bands suspiciously at either the tile edges or tie point spacing but, it’s not the static you are seeing.
We need to see where the vertical bands are coming from.
The banding doesn’t appear in Sentinel-1 or TanDEM-X that I’ve processed. Why is ENVISAT any different?
On a side topic, I’d like to see how many people on here use those missions. Is there a way to create polls?
Thanks for processing Iveci,
The interferogram I showed is of the pair 2007-12-26 and 2008-03-05. Why did you use 20k gcp instead of 2k? To me it seems that in this high coherent area even 100 gcp should be sufficient.
Have you been able to find the reason for the banding? I can look into this if you bring me up to speed with your latest findings.
We don’t see the banding problem anymore and we can’t reproduce the original problem. The Envisat Interferograms look good.
That’s great. Would you attach your processing graph? I wonder how many GCPs you’re using. I hope you managed to bring this down to a reasonable number, like 2K (instead of 20K).
I did not process the data with a graph. Instead I just ran Apply Orbit operator to both master and slave, then ran Coregistration with the default parameters. The number of GCPs in this case should be 2k. Some minor changes have been made since August and they should be in the next release.
I’ve tried again with today’s version of all git master branches. Specifically, I ran the coregistration feature using 3 images. The interferogram of the first master-slave pair looks fine:
The second one doesn’t though:
I’m using all the default parameters except for the interpolation kernel: Truncated sinc (16 points). The number of GCPs is 2K.
Have you tried to coregister a stack of 3 images or more? This is all TSX (stripmap) data by the way, acquired with an 11-day temporal baseline.
Also, I’m getting this message:
SEVERE: org.esa.snap.core.gpf.operators.tooladapter.ToolAdapterIO: Failed scan for Tools descriptors: I/O problem: /opt/snap/java
I’ve done some further testing and the quality of the coregistration (in terms of interferometric coherence) improves by coregistering all master-slave pairs as separate two-image stacks.
For example, instead of calling the Coregistration operator with 3 images, one of which is the master, I call the Coregistration operator twice with master-slave1 and master-slave2.
Are you experiencing the same?