I see. Would be worth trying to perform Range Doppler Terrain Correction (or SAR simulation terrain correction) first.
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.
I see no problem in performing the multi-temporal filter after coregistration and terrain correction.
Maybe this presentation is useful. It goes through several coregistration approaches.
ESA SNAP/Sentinel-1 Toolbox SAR - Coregistration Approaches & Change Detection
1 Like
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?
I would suggest the following chain:
- applying orbits
- calibration
- terrain correction
- stacking with the stack tool, based on the product geolocation with no resampling
- and multitemporal speckle filtering
2 Likes
I will try to reproduce it if you tell me exactly which products are slice-assembled and what else are you stacking with this product
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
2:
S1A_IW_GRDH_1SDV_20170124T175717_20170124T175742_014977_018735_22F4
S1A_IW_GRDH_1SDV_20170124T175742_20170124T175807_014977_018735_A87F
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
Ah OK. So if I understand the workflow should look something like this:
Currently testing…
Guess this post/thread could be somewhat related :
OK I have tried your suggestion, sadly it results in the same issue as my original post! I look forward to hearing if you are able to reproduce.
ok so its is not any better than you initial results? lets check it than 
1 Like
@mfitrzyk @mengdahl
Have just checked if the issue still exists when using SNAP 6.0.0 - it does sadly! My method to reproduce:
- Calibrate single dates with:
calibrate.xml (3.8 KB)
For files:
- S1A_IW_GRDH_1SDV_20170804T175746_20170804T175811_017777_01DC8F_54EC.zip
- S1A_IW_GRDH_1SDV_20170816T175747_20170816T175812_017952_01E1DE_DD6F.zip
- S1A_IW_GRDH_1SDV_20170828T175747_20170828T175812_018127_01E727_F362.zip
- Slice assemble and calibrate the “multi slice dates” (seperately for 20170810 and 20170822) with:
slicecalibrate.xml (4.2 KB)
- S1B_IW_GRDH_1SDV_20170810T175658_20170810T175723_006881_00C1C6_BDFA.zip
- S1B_IW_GRDH_1SDV_20170810T175723_20170810T175748_006881_00C1C6_688F.zip
- S1B_IW_GRDH_1SDV_20170822T175659_20170822T175724_007056_00C6DA_5DFA.zip
- S1B_IW_GRDH_1SDV_20170822T175724_20170822T175749_007056_00C6DA_523B.zip
- Coregistration of the calibrated outputs (master=20170804) with:
coregistration.xml (3.6 KB)
- S1B_IW_GRDH_1SDV_20170106T175654_20170106T175719_003731_00668A_0A76_Orb_Cal_TF
- S1A_IW_GRDH_1SDV_20170112_Asm_Orb_Cal_TF
- S1B_IW_GRDH_1SDV_20170118T175654_20170118T175719_003906_006BA3_5A02_Orb_Cal_TF
- S1A_IW_GRDH_1SDV_20170124_Asm_Orb_Cal_TF
- S1B_IW_GRDH_1SDV_20170130T175654_20170130T175719_004081_0070DE_3CEF_Orb_Cal_TF
-
Multi-Temporal-Speckle-Filter with:
multitemporalspecklefilter.xml (1.7 KB) -
Terrain-Correction with:
terraincorrect.xml (3.3 KB)
Output issue:
I have attempted to digitize the area (red outline with cross hatch) that I can see is effected by poor coregistration
Close up of the center (looks pretty good):
Close up of the top right (NE) corner showing blurriness:
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?
OK, thats a real shame!
So I’ve been using @mfitrzyk workaround:
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!
Ok so finally I have found time to check this issue.
First I applied slice assembly to the scenes which required this step, after that I made a subset to fit the other scenes (otherwise it also becomes too big for processing)
Maybe if you don’t need whole scene it would be useful to make subset also for the other files - but this depends on your AOI.
than I applied all the steps that you mentioned before so: border noise removal, thermal noise removal, calibration
in the following step I checked few options :
- one was to perform DEM assisted coregistration (worked perfectly for whole scene) and TC ->no shift for the stack
- terrain correction and than stacking based on the geolocation - also worked well
I am going to add some of my results in a while
1 Like
Awesome, thanks for taking a look! I have a big AOI so would prefer not to do multiple subsets…
So did you try ‘normal’ coregistration -> TC then?
I think I’ve actually got it to work but wanted to run another test to make sure before reporting back here. All I have done is increase the “Warp” tools “Warp polynomial order” parameter from 1 to 2…
Have added your DEM assisted coregistration -> TC method onto my todo list, for some reason I had originally ruled this out as an option for myself.
In fact both methods shall give you good results - if you perform coregistration and than TC OR you do TC and than stacking.
What I have noticed is that there might be a problem with image of 18/01/2017 (still don’t know why) - in this case performing first coregistration and increasing Warp polynomial order might help.
Talking about the subset - If I were you I would subset my data to the AOI in order to decrease computing effort.
1 Like