S1 TOPS co-registration doesn't seem to work


I’m trying to co-register a pair of S1 SLC images but the slave image result is only zeros (for the i and q bands) and NaN (for the intensity band). The images are in the same acquisition mode, pass and track. I have six images from 2015 and tried several different image pair combinations. All result in NaN for the slave image.

SNAP 2.0.2, Windows 7, 16 GB ram.

I’m using the built-in S1 TOPS Coregistration tool and choosing the IW3 band (VV). I’m also following the instructions for the Sentinel-1 TOPSAR Interferometry tutorial available on step.esa.int. I’ve also tried each step manually (i.e. not using the graph) and the result is the same.

Since the area I’m studying is above 60N, I’ve used an external DEM (geotiff, wgs84). I’ve also tried the Getasse30 DEM. Same results

Any and all help is appreciated,

In the backgeocoding, try unchecking the “mask out areas with no elevation” checkbox.
Also, if you do the processing manually, check at which step do the slave bands become 0.


Thanks for the reply. The problem arises during the back-geocoding stage. I’m re-running the process with the “Mask out areas…” unchecked. It’s taking a lot longer time so maybe that’s a good sign.

I’ll return soon with an update.

Did you resolve this? I am having the same issue running through this tutorial: https://media.asf.alaska.edu/uploads/pdf/current_data_recipe_pdfs/generate_insar_with_s1tbx_v4.1.pdf

Make sure you have the latest updates. The url to the default srtm dem has changed. Without it, a lot of things may not work properly.

Thank you! I installed the latest update and everything worked great.

I just re-installed SNAP and updated everything, but the same error is occurring again, the slave comes out as NaN every time. Have tried the “Mask out areas…” to no avail, a different pre-defined DEM, doing the back-geocoding manually and in batch. I got enough space on my SSD and the disk everything’s saved on, enough RAM, enough everything, but the slave layer is either NaN or the next function throws an exception because there’s no data to read.

Is there anything else I can do?

could you please share the product IDs of the images you used (and which swath and bursts)?

S1A_IW_SLC__1SDV_20191202T172140_20191202T172209_030172_0372A8_12F7 IW1 VV Burst 7
S1A_IW_SLC__1SDV_20191214T172139_20191214T172209_030347_0378B5_B5C1 IW1 VV Burst 7

S1A_IW_SLC__1SDV_20191207T172936_20191207T173005_030245_037531_8DEC IW3 VV Burst 3
S1A_IW_SLC__1SDV_20191219T172935_20191219T173005_030420_037B3F_0FB0 IW3 VV Burst 3

There’s White Island, New Zealand and a lot of sea in those. It’s always the slave causing the problem, no matter which of them I use.

I have downloaded the first pair, applied Split (IW1, burst 7), Orbit file, BackGeocoding (SRTM 1Sec), intererogram generation, debursting and multi-looking / filtering (just for visualization purposes) and this is the result:

I wonder what is different in your case.
You said you had done the BackGeocoding manually and in batch - what do you mean with it?

Thanks for your reply!

I found a post somewhere that some people could not get the function to work if they used it from the menu, as a single function, but that it worked as part of a processing tree in batch processing. I don’t know how it would make a difference, but tried it anyway to no avail.

I used some scenes nearby from a different date a week ago and that worked perfectly, the results were just very boring. So I wanted to try the eruption of White Island in December. I can see the island in the bursts from my last posts, so it’s not empty, and the SRTM is available for that place. But somehow the slave is never written properly.

I understand, there is the “S1 TOPS Coregistration” module which combines all necessary steps. But it is very memory consuming, so I prefer to execute the single steps.

It could be that if the slave largely differs from the master because of the eruption, the standard BackGeocoding fails. But I have never seen it. Are you using the latest version of SNAP with all updates installed?

There’s no visible change in the volcano in Sentinel-2 images at least. I know it doesn’t mean much just seen from above, but at least there’s no major change, no missing flank or anything. The local GNSS site doesn’t show anything out of the ordinary, either, so the island hasn’t suddenly moved a couple meters. There is a visible difference in intensity between the individual scenes but nothing drastic. It shouldn’t matter that most of it is sea, should it? There’s a tutorial using some larger islands so I didn’t expect this to matter.

I reinstalled SNAP over this yesterday and updated it and it says it’s up to date. So are my drivers and operating system.

I cannot reproduce this error, sorry.

Thanks for trying :slight_smile:

In another topic we found out that the orbit file which was downloaded decreased the quality of the data.
Comparing the baselines before and after application of the orbit files could be worth a try: Coregisteration is not correct!

I had installed the latest version of SNAP but S1 TOPS Coregistration, doesn’t seem to work can anyone help me how to rectify this issue

we need more information

I had kept for coregistration process 2 days ago of pre and post images but in the process bar it is showing only 1%, there is no further movement in process.

please select SRTM 1Sec HGT instead of SRTM 3Sec in the BackGeocoding step because the source of the latter has changed and SNAP is currently not able to access it.

More on this here: SRTM ZIP-files are corrupted or not found