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
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 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.
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 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.
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 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.
