Slice Assembly Causing Product Offset

Hello! I have noticed some problems with product positioning after applying the Slice Assembly tool, which is particularly apparent after subsequent Terrain Correction. However, when processing each product individually, this does not occur.

GRD Products of different dates show good levels of co-registration, even before any processing steps have been applied. However, once the Slice Assembly is run, a noticeable offset occurs from between products and from ground truth data.

The following has been observed:

  • Amount of offset is not equal for all capture dates
  • Amount of offset appears to change when the position of the start of the slice changes
  • Offset is not uniform across the image
  • Offset is worse the further away from the “first” product in the assembly, i.e. for Descending Tracks, offset is worse further south; Ascending Tracks, offset is worse further north

Please could you tell me what is happening here, or suggest any additional processing stages that are required to fix this problem.


Toolbox Version: Sentinel-1 Toolbox 2.0.3

Operating System: Linux (Ubuntu 14.04), Windows (7)

Relevant satellite products: Various (any slice assembled product)
example:
S1A_IW_GRDH_1SDV_20150729T174926_20150729T174951_007029_0098CB_963D.SAFE
S1A_IW_GRDH_1SDV_20150729T174951_20150729T175016_007029_0098CB_3F44.SAFE

Processing steps:
Problematic output:
Apply Orbit File (Sentinel Precise)
Radiometric Calibration
Slice Assembly <-- offset shown at this step
Create Stack
Terrain Correction (SRTM 3s - Auto Download)

Correct output:
Apply Orbit File (Sentinel Precise)
Radiometric Calibration
Terrain Correction (SRTM 3s - Auto Download)

I am using the slice assembly quite often now. I never experience such an offset. Just to be sure: the image you showed (with the wrong alignment) is before or after the Terrain correction? and the stack is created among which images?

Both images are after terrain correction. This was done so that the products can be compared to existing data with a known projection, such as the red field boundaries shown in the image. However, the issue appears to be produced at the Slice Assembly stage, and an offset between products of different dates can be seen when synchronising views and comparing pixel locations within SNAP directly.

The stack was included in the processing chain to group products from multiple dates. It is the basic Create Stack operation and does not involve co-registration or warping.

Since Create Stack does not coregister it should be the last step after terrain correction, IMO.

It would be nice to know if the shift is due to the create stack operator…can you give it a try and see the results without performing it?

Array is looking into this issue. In any case, it looks like your processing-steps are in incorrect order, please try:

Apply Orbit File (Sentinel Precise)
Radiometric Calibration
Slice Assembly
Terrain Correction (SRTM 3s - Auto Download)
Create Stack

I do not believe that this is a result of the Stack operator. I am able to see the offset directly after the Slice Assembly which occurs before the stack is created (below)

As shown in the table, there is no significant offset between the three dates at the Radiometric Correction stage. However, hen the Slice Assembly is applied to each date, a visible offset occurs. This was assessed using the cursor/view synchronisation across all six products in SNAP (highlighted red in each scene).

It is pretty strange, tough. I’ve no shift if I do not use the stack operator before the terrain correction. I have some strange shifts if i use it before. I compare my results with optical data…I hope this may help…

I’ve run some Slice Assembled products through the Terrain Correction without creating a Stack and the geo-rectification appears to be much better. It is also consistent between products. Thank you both for your advice.

Though I am still curious as to why SNAP is presenting such an offset in the view windows (such as my screen-shot above).

Yes, this also piqued my interest… I have to use other software to really understand if there is a shift in the products or not… the other question is about the create stack operator… in the end it is not a reliable tool to stack images before TC, isnt it?

No. Create stack is not a subsititute for coregstration.