I had some problems trying to coregister 2 S1GRD data recently. I haven’t had time to check the forum to see if these problems have been reported before and apologise in advance if they have.
First of all, when I coregistered my two pieces of data conventionally (Radar/Coresgitration/Coregistration function), I got two blank results (no problem of space on my computer, SNAP up to date…). I know that this problem is recurrent and can have multiple origins, so I won’t dwell on it. What’s more, using the following graph and the graph builder, I get a correct result.
Secondly, the option initially proposed for Resampling Type in Create Stack is NONE, which causes an Error org.jblas;NativeBlas… I think that for the sake of clarity, it would be a good idea to propose another base method (preferably Nearest Neighbour, as this option doesn’t physically change the image).
Thirdly, I’ve observed the opposite phenomenon with Warp’s Show Residuals. If this is not ticked VS code opens the residual during the process, and if I tick it it doesn’t open it for me.
Fourthly, using the graph provided in Problem 1, I obtain the following results:
My problem is as follows: the resampling has obviously not been carried out with a Nearest Neighbour, as the Slavic image seems “filtered” and I have negative values as shown in the Colour Editor… I imagine that a default value bypasses the user’s selection.
I would be happy to provide you with more information, and if I get some time I will take a look at the Git codes to try to understand the origines of these problems.
Trying to study a bit more this problem, I discovered an other issue. As I explained I have negatives value in my slave image. But when I use the “Linear to/from dB function”, these negatives values (x) are transformed to the dB values of the corresponding positive values (10*log10(-x)), instead of NaN. I think it is something which should be corrected.
Here are the two data I used :
S1A_IW_GRDH_1SDV_20220604T055236_20220604T055301_043509_0531E5_DC1B.zip
S1A_IW_GRDH_1SDV_20220616T055236_20220616T055301_043684_05371A_E51A.zip
The processing steps I did was just using the Radar => Coregistration => Coregistration function, and I only changed the CreateStack Resampling Type option to Nearest Neighbour.
The xml files which “worked” (error for residual display, method for resampling not carrying out, weird Linear to/from dB function effect on negative values) is provided in my first message.
I tried it again today, still not working.
Don’t hesitate if you need more informations / want me to send you the data I used.
I agree with that, but I don’t think it is the default method we want, as users might not change it and end up with a non-resampled output. I don’t think this situation is the most used case.
Hi Nathan,
We have coregistered the two products using the Radar/Coregistration/Coregistration operator with all the default setting and got the proper result (the image below is the coregistered secondary image).
We have also coregistered the two products with your graph (Coregistration.xml). We have changed the “Resampling Type” in CreateStack to “NONE” and changed “Interpolation Method” in Warp to “Nearest-neighbor interpolation”. This is to avoid the change of pixel values introduced by the interpolation. Below is the coregistered secondary image. Here you can see that the image is not “filtered”. The reason it looks filtered in your case could be that “nearest neighbor” interpolation is used in CreateStack.
