I’m trying to coregister Sentinel-1A and Sentinel-1B GRD scenes (from the same relative orbit) for VV polarisation for 5 dates in January 2017. The scenes are all around 90% land. Due to the slice shifts I have slice-assembled the 2 S1A scenes (after calibration) and then attempted to coregister with a non slice-assembled master (a S1B scene). However, when viewing the coregistered result in RGB (with a mix of S1A and S1B) I can see significant blur in the top 10% and bottom 10%. When viewing only the 3 S1B bands as RGB the result looks good:
So 80% of the slice-assembled coreigstration outputs seem to be OK (ignoring some slice-assemble border artifacts). But I’d really like to get to 100%!
I have changed the “CreateStack” “Initial Offset Method” paramater from “Orbit” to “Product Geolocation” but this only resulted in me losing (no data) one the S1A slice assembled coregistration output bands to “not enough GCPs” even with 4000 Cross-Correlation GCPs and a Warp RMS Threshold of 0.05. Have also tried processing without terrain flattening but this didn’t help.
My initial calibration xml graph:
Apply-Orbit-File, Remove-GRD-Border-Noise, ThermalNoiseRemoval, Calibration (to beta), Terrain-Flattening (with SRTM 1Sec HGT auto download)
SliceAssembly on any dates that need it.
resamplingType = NEAREST_NEIGHBOUR
extent = Minimum
initialOffsetMethod = Orbit
[Side question, would like to know how much of an impact the “Find Optimal Master” button in the SNAP GUI has on the coregistration process and if there is something like this available to GPT/snappy?]
numGCPtoGenerate = 4000
onlyGCPsOnLand = true
SNAP Version: 5.0.8
S1TBC Version: 5.0.5
Additional questions I had while trying o resolve this:
In the coregistration graph xml I also notice that for the “Warp” tool there is a “demName” varaible that defaults to “SRTM 3Sec” - should I use the same "demName"s as Terrain-Flattening and Terrain-Correction - “SRTM 1Sec HGT”?
Am I right in thinking that I cannot use the “DEM Assisted Coregistration with XCorr tool” as the image boundaries do not overlap fully?
Thanks for your response but all of the scenes that I am using are ascending (relative orbit 30):
OK understood, I will have a go at that. I plan to perform multi temporal speckle filtering after coregistration, therefore wouldn’t terrain correction before this be less than ideal? Sorry I should have made my post clearer.
So performing Range Doppler Terrain Correction before Coregistration has worked for the whole scene!
I am still concerned about processing in this order however. Maybe @mengdahl can elaborate on:
@css thanks for the link. I found page 82 interesting.
@mengdahl indeed. I have no issues when just using ‘un-shifted’ scenes, only when I add slice-assembled scenes into coregistration do I see issues. Maybe someone can try reproduce to check I’m not doing something stupid?
Then I coregister the 5 files:
Before I check it you can also perform another trial. I have noticed that you first apply orbits and than slice assembly and this could be possible problem, it could lead to some differences. Not sure if the difference could be so big though… It could also explain why TV products stacked based on the geolocation work ok. Let me know if it has solved your issue
But this method has a real performance impact (around 3 times slower for me) and I have noticed the occasional output band with less than ideal coregistration (though not as poor as the blurriness above).
I will attempt co-registering slice-by-slice next, thank you for that idea!