Coregistration of Sentinel-1 GRD with slice-assembled scenes - blurry outputs

Hi All,

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:

  1. My initial calibration xml graph:
    Apply-Orbit-File, Remove-GRD-Border-Noise, ThermalNoiseRemoval, Calibration (to beta), Terrain-Flattening (with SRTM 1Sec HGT auto download)

  2. SliceAssembly on any dates that need it.

  3. Coregistration parameters:
    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?

í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):

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:

  1. applying orbits
  2. calibration
  3. terrain correction
  4. stacking with the stack tool, based on the product geolocation with no resampling
  5. and multitemporal speckle filtering

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:


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

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 :wink:

1 Like

@mfitrzyk Guessing you’ve not had a chance to test yet? :slight_smile:

@mfitrzyk @mengdahl
Have just checked if the issue still exists when using SNAP 6.0.0 - it does sadly! My method to reproduce:

  1. Calibrate single dates with:
    calibrate.xml (3.8 KB)
    For files:
  1. Slice assemble and calibrate the “multi slice dates” (seperately for 20170810 and 20170822) with:
    slicecalibrate.xml (4.2 KB)
  1. 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
  1. Multi-Temporal-Speckle-Filter with:
    multitemporalspecklefilter.xml (1.7 KB)

  2. 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!