Hello,
I’m trying to coregistrate two L-band SAR images using SNAP’s coregistration algorithm.
In SNAP’s GUI, I click on Tools --> Graph Builder --> Graphs --> Radar --> Standard Graphs --> Coregister.
I would like to understand how your coregistration algorithm internally works for my own research.
Do you have any documentation or papers to share about that?
Many thanks !
the one you mention is based on this algorithm:
Thanks a lot @ABraun for your quick reply !
In fact, I was more like looking for the scientific paper you implemented this algorithm from. Do you happen to have it?
Actually, I’m asking to understand if:
For now, both of my input images are in i/q format, geocoded, not filtered, and have the same resolution.
I input “nearest neighboor” as resampling type, “product geolocation” as initial offset method and bilinear interpolation in “Interpolation method”.
The coregistration is perfectly done, but I notice that the pixel values of slave image change.
I wanted to know if it was normal, and if the parameters I used where suited to my inputs
yes, that is possible as long as you use “product geolocation” as initial offset method (as you did).
Resampling is rather a matter of data origin. If you want to preserve the original pixel values, (e.g. for classified rasters) you select nearest neighbor. If you want to allow averaging in case of shifted or rotated pixels. The reason why your pixels values still change could be that the pixels are shifted to another location to match the primary image.
I made sure the coregistered and non_coregistered images are perfectly superposed when I was comparing them, yet, I still get pixel differences (coregistered image is overall darker).
Attached are the images and the kml file addressing the issue I’m talking about.
(For the KML to work propely, it must be put in the same folder as the images).
P.S : before coregistration, both master and slave images are processed using the same DEM.
result.kml (1.6 KB)are both images scaled over the same valur range in the color manipulation tab?
You can set pins and extract the values from both rasters with the pin manager, to get comparable pixel value pairs.
Regarding you workflow: If you are not planning to do InSAR, which is anyway impossible after terrain correction, there is really no benefit to carrying i and q around. You should generate intensity images and work with those.
Bilinear interpolation changes pixel values and Andreas pointed out, you should use nearest neighbour everywhere.
BTW it looks like you are resampling the data twice, 1st at the create-stack phase and for the 2nd time at the cross-correlation and warp stage - this should be avoided if possible. As your data is already geocoded you might be able to choose “None” at at the stack generation stage and avoid the first resampling. Or alternatively if you are working with intensities only, you might be able to skip cross-correlation and warp and to use Create Stack only, with nearest neighbour as the resampling method.
Sorry for my delayed response, but I had to run some tests on several slave images in order to give you a reliable feedback.
The pixel values were effectively different.
@mengdahl : That solved my problem. (I went with “None” at stack generation). The pixel values are now the same.
Also, thanks a lot for pointing out the resampling matter. I now understand why I had a “different-pixel spacing” problem between coregistered images and the original ones even when I set the resampling type to “None” in the stack generation stage.
Again, thank you both for you help and for your quick replies !
@mengdahl : One more question, in your last response, you said that, since my inputs are geocoded, I would be able to choose “None” at the stack generation step, and it’s effectively the case.
But, when I try to coregister:
where:
A is an already coregistered image using SNAP
B is a geocoded image.
I get this Warning: “Resampling type cannot be NONE pixel spacings are different for master and slave”
I guess this is due to the fact that image A has been resampled during the warp phase (when it was being coregistrated in SNAP).
But, even with this warning, I can still run the coregistration normally.
My question is: what resampling type does the program use in this case if “NONE” is not an option (according to the warning) ? Does it really resample?
Many thanks
NONE works for S-1 GRD with a fixed pixel spacing.
What happens if you try to do everything in create-stack using nearest neighbour resampling?
You mean skipping the cross-correlation and warp steps and only sticking with the “create-stack” ?
If that’s what you meant, I guess I should be working with intensities and not i/q images as you mentioned here:
I tried to convert my images to intensities but, for now, it’s not possible as the process gets killed (I guess my code is not scalable yet as my images are 10Go each…).
So, I tried to do what you described, but using the i/q images, and the result is not well co-registered.
After that, I used nearest neighbor resampling for both:
create-stack phase (since I don’t use S-1 GRD)
and cross-correlation/wrap stage.
And it works fine with no pixel changes
Thanks again @mengdahl !
Hmm conversion from i/q to intensity is a simple single operation and should not crash. How did you do it?
@mengdahl: It is very simple indeed and used to work with my python code on image slices, but it didn’t scale for large images.
The issue was quite basic, and I solved it, the intensity images are now being generated for the whole images.
Gonna keep you posted 
I only have one question about this, why should skipping cross-correlation step help us co-registrate?
I mean, as far as I know, both coarse and fine coregistration rely on cross-correlation (to find integer and sub-pixel shifts).
Am I getting it wrong?
For SNAP newbies who (like me a couple of days ago) didn’t really understand what each parameter in each coregistration step correspond to, please refer to this document: https://appliedsciences.nasa.gov/sites/default/files/SAR%20Disasters%20Part%203_0.pdf
Starting from page 43, the use of some parameters is explained. The choice of some parameter values is also interesting
I think it’s me who has been confused since lately I’ve only used it with S-1 GRDs that align very well to start with and resampling “None” can be used.
