Maximizing S1 GRD stacking accuracy?

Microwave Toolbox
#1

I am trying to stack 30 S1 GRD products. Some of the stacked images have a shift (offset) of a few pixels from the others using Dem assisted Xcorr. I am not using precise orbital data. What is the best way of improving co-registration accuracy?

#2

Can you please detail the full process you’re trying to do*? Few pixel misregistration is strongly abnormal.

*something like Read->Apply orbits -> …

#3
  1. Read
  2. Subset
  3. Calibrate to Sigma 0
  4. Dem Assisted Corregistration with Xcorr
#4

What if you apply the orbits first?

#5

I want to avoid using precise orbits, because I need to process change detection immediately after a product is released (before precise orbits are available).

#6

I understand. But you can use restituted orbits for example which are already quite precise.

Also, I just want to know if it was related to the orbits. I’m trying to find where the problem is

#7

Do you know how long it takes for restituted orbits to be available after S1 product release?

#8

A couple of hours -> https://qc.sentinel1.eo.esa.int/aux_resorb/

#9

Ok, I will attempt using orbits to see if results are improved.

1 Like
#10

HI,

I am not sure that the problem lies actually with the orbit file as the data might have been processed with RESORB files.

You can check which orbit was used looking in the manifest file (with a simple grep). You will see if all images were processed with the RESORB. If not then, you could verify if the data presenting a shift are the one with no RESORB.

For our info please dump the list of products highlighting the one being faulty.
Reg.
N Miranda
S-1 Data Quality Manager

#11

Dear Nuno, I am using residual orbits and not precise for my products because I need to process the data within 24 hours of product availability. Using residuals helped stacking accuracy but in some pairs there is still 1 or 2 pixel shift.

#12

I guess the request was rather to give the exact names of the images and pairs that cause the troubles, for investigation purposes

#13

The usage of restituted (not residual) with respect to precise won’t change much. We are talking about few cm differences while 1-2 pixel shift at GRD level means several meters.

So we need the list to understand:

  • which product is faulty
  • investigate further why. There could several sources:
    • RESBORB issues? It happened in the past.
    • differences in the processing parameters leading to this>
#14

shift1
shift1.PNG1762×1286 86.2 KB

shift2
shift2.PNG1766×1291 177 KB

This is the shift after applying restituted orbits and stacking.

The products are:

S1A_IW_GRDH_1SDV_20150108T030926_20150108T030951_004074_004EC3_B908
S1A_IW_GRDH_1SDV_20150929T030934_20150929T030959_007924_00B115_131E

#15

Could you please clarify which one is the good and the faulty, according to you?

#16

Based on comparison to other images, it seems the image from Sep 29 2015 is shifted. (S1A_IW_GRDH_1SDV_20150929T030934_20150929T030959_007924_00B115_131E)

#17

Dear SteffenDavies,

Considering the date of the S-1A very (early in the mission) I wouldn’t be surprised that some images could be affected by a wrong location as at time we were not using all the time the restituted orbits. We will look into that.

However, I understand that the role of the " Dem Assisted Corregistration with Xcorr" is to coregister the images over a master using a DEM to correct for large time shifts. Hence even if there is an error in the original data, it should be corrected at stack level. I am not a SNAP expert hence external confirmation would be welcome?
If this is correct , I wouldn’t exclude a bug in SNAP or in your procedure.