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.
Processing Steps:
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.
Coregistration parameters:
“CreateStack”:
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?]
“Cross-Correlation”:
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?
íf the images are taken in ascending and descending orbits it is tricky to get a proper coregistration before terrain correction because of the many geometrical shifts.
You can try to perform Range Doppler Terrain Correction first and then use the coregistration tool (using geolocation instead of orbit infrormation).
Thanks for your response but all of the scenes that I am using are ascending (relative orbit 30):
S1A_IW_GRDH_1SDV_20170112T175742_20170112T175807_014802_0181C5_D63D
S1A_IW_GRDH_1SDV_20170124T175717_20170124T175742_014977_018735_22F4
S1A_IW_GRDH_1SDV_20170124T175742_20170124T175807_014977_018735_A87F
S1B_IW_GRDH_1SDV_20170106T175654_20170106T175719_003731_00668A_0A76
S1B_IW_GRDH_1SDV_20170118T175654_20170118T175719_003906_006BA3_5A02
S1B_IW_GRDH_1SDV_20170130T175654_20170130T175719_004081_0070DE_3CEF
S1A_IW_GRDH_1SDV_20170112T175717_20170112T175742_014802_0181C5_613F
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.
This is odd, it should be very easy to co-register these scenes just about perfectly (same orbit track + small orbital tube). A simple shift/rotation should be all that is needed, based on orbit info.
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?
Hey that would be brilliant. So I have 2 slice-assembles:
1:
S1A_IW_GRDH_1SDV_20170112T175717_20170112T175742_014802_0181C5_613F
S1A_IW_GRDH_1SDV_20170112T175742_20170112T175807_014802_0181C5_D63D
Then I coregister the 5 files:
S1B_IW_GRDH_1SDV_20170106T175654_20170106T175719_003731_00668A_0A76
S1A_IW_GRDH_1SDV_20170112_sliceassemble
S1B_IW_GRDH_1SDV_20170118T175654_20170118T175719_003906_006BA3_5A02
S1A_IW_GRDH_1SDV_20170124_sliceassemble
S1B_IW_GRDH_1SDV_20170130T175654_20170130T175719_004081_0070DE_3CEF
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
Hmm, it looks like the current co-registration - method breaks down with long data-takes. I suggest you try to find a work around by co-registering slice-by-slice.
edit: I’m still a bit surprised to see this @mfitrzyk could you have a look?
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!