Hello,
I’m trying to coregister a stack of 8 S1 GRD images using SNAP v10.0.0 in Ubuntu 22.04.
Images have been preprocessed with calibration, subset and terrain correction. They are all ascending and on the same area.
Depending on the image I choose as master, I get
the master and slave 1 bands empty and the other slaves ok
OR
the processing hangs at some point while cross correlating one slave, with zero CPU usage and need to cancel and close SNAP to actually stop (the “Cancel” button just stops the slide bar but processing keeps going in background…)
No errors whatsoever.
I had a similar problem with other 8 images of the same area but changing the master at some point it worked.
Notably, I tried also coregistering only 4 images and again got the first two bands empty.
Any clues about what’s happening? Is there any mean to check what’s wrong?
I also encounter this problem in SLC coregistration. It happens only at first slave bane. I have complained about this before but no feedback from the community just like nobody has this problem. However, I have tried this on 10s computers with both Linux and Windows system, and all of them have this problem.
My temporary solution is to do coregistration using only two images, in this condition, the slave band will write out correctly. You can copy the band file in .data folder to replace the incorrect one in your old dim product.
We still need developers to look at this problem, I hope they will notice.
A figure of empty band:
left upper row: intensity of master
right upper row: real band (i) of slave 1
left lower row: intensity of slave 1
right lower row: image band (q) of slave 1
Thank you for reporting this issue. SNAP developers can only fix issues that they can replicate on their systems - please provide the full information required to make the issue manifest. Please check the FAQ for what is required in the report.
For my time-series of 7 S-1 SLC files, I tried with the generic coregistration command and now I’m getting:
Index -1 out of bounds for length 3
I’m using Bilinear Interpolation, orbit as the initial offset method and Minimum as the output extents in the CreateStack tab.
I’ve tested it with just two images and no problem. As soon as I start adding more scenes I get errors, even keeping the same options. With 3 scenes I get this:
“The specified region, if not null, must intersect with the image’s bounds”.
Here’s where my 7 scenes are, to make sure you’re not about to ask me if they overlap:
Please don’t use generic co-registration with S-1 SLC TOPS data. Are the related tutorials difficult to identify or how come you decided to use generic coregistration?
I had so many problems with S-1 SLC TOPS back geocoding that I used generic coregistration. I’m now using back geocoding: with just two images, I’m getting the master image right, but the slave image is only made of NaN.
You should use S-1 TOPS co-registration as it is the tailored method for TOPS data. If the recommended processing graphs for co-registration do not work, your SNAP installation must be corrupted. We have many thousands of users and S-1 InSAR is a common operation, so we would already know if this was a problem with SNAP.
I have 7 SLC S-1 dates that I need to convert to C2 terrain corrected. So far I have been able to run TOPSAR-Split > Apply orbit > Calibration for each date. Then, I managed to run S-1 Back geocoding thus resulting in a stack of 7 co-registered dates. I also managed to run Deburst on the stack.
However, I’m not sure how to proceed from here. If I try to generate C2, I get a stack of 7 dates where all are equal to the first date of the stack. If I run stack split I get an error due to memory (the error says something like can’t create buffer).
Did the same for:
S1A_IW_SLC__1SDV_20190623T094914_20190623T094941_027805_03238A_4D88
S1A_IW_SLC__1SDV_20210624T094927_20210624T094954_038480_048A73_DE9D
S1A_IW_SLC__1SDV_20230626T094938_20230626T095005_049155_05E932_9116
Applied S-1 back geocoding to these 4 datasets. Got this for q_IW2_VH_mst_21Jun2017
Now, if I run the “normal” coregistration process and CHANGE the name of the output file, I get a coregistered stack in which the first 5 bands (out of 28) are either empty or subsetted (the choice of being empty or subsetted seems random). If I let the system choose the output filename, the coregistered stack is right. How odd is this?
