S1 SLC Slave Intensity "oscillation" effect after Orb_Cal_Back_ESD_Deb

Dear all,

We have a processing chain that processes S1 SLC images. A part of the chain is composed by the following steps:

  1. Input SLC splitting in sub-swaths
  2. Apply orbits, calibration, back geocoding, enhanced spectral diversity
  3. Backscattering debursting
  4. Merge, Multilooking, Terrain Correction

At the end of the chain we found that a sort of “oscillation” effect in the slave image as shown in the attached example.

Such effect is present as soon as in output from the second step : Apply orbits, data calibration and coregistration.
See attached an example for 1 subswath : master (left), slave (right)

In the attached example the following S1 SLC pair has been used:
Master: S1A_IW_SLC__1SDV_20180307T060825_20180307T060852_020905_023DDA_32C4
Slave: S1B_IW_SLC__1SDV_20180301T060738_20180301T060805_009834_011C88_6C27

The issue occurred also in other S1 pairs.
Inverting master and slave, the issue occurs always in the slave image
The issue occurred by using both SNAP v5 and v6.

Here attached also the graph used for the second step : Orb_Cal_Back_ESDgraph_Orb_Cal_Back_ESD_Deb.xml (5.6 KB)

In the product metadata it is reported that the follwoing orbit files have been used:
Master:
orbit_state_vector_file Sentinel Precise S1A_OPER_AUX_POEORB_OPOD_20180327T120816_V20180306T225942_20180308T005942.EOF.zip ascii Orbit file used

Slave:
orbit_state_vector_file Sentinel Precise S1B_OPER_AUX_POEORB_OPOD_20180321T110558_V20180228T225942_20180302T005942.EOF.zip ascii Orbit file used

Do you have any hint about any possible cause?

I would include “Remove Antenna Pattern”, “Thermal Noise Removal” and “Radiometric Calibration” to the product at the beginning.

Dear ABraun, thanks for your reply.

“Remove antenna pattern” should be valid on ERS/ENV data but not for S1, see also here:

I tried Thermal noise removal but it returned an empty product (note we are using S1 SLC not GRD and also need to maintain phase information)

Calibration was already applied as mentioned in the first post.

The issue seems to be generated in one of the BackGeocoding or “Enhanced spectral diversity” steps.

We’ll have a look. It may be related to the problem reported in Crop classification using SENTINEL-1A SLC data but these are vertical rather than horizontal

Dear Luis,
did you have the chance to check the issue ?

Dear all,

After further research, we noticed that the “oscillation effect” already happens in the slave after the back geocoding step.

To summarize: After splitting of the SLC in subswath’s, applying the orbit files, applying calibration and back-geocoding both images, we notice an “Oscillation effect” in the slave image as shown in the example. Any suggestions?

In the attached example the following S1 SLC pair has been used:
Master: S1A_IW_SLC__1SDV_20180307T060825_20180307T060852_020905_023DDA_32C4
Slave: S1B_IW_SLC__1SDV_20180301T060738_20180301T060805_009834_011C88_6C27

The issue occurred also in other S1 pairs.
Inverting master and slave, the issue occurs always in the slave image
The issue occurred by using both SNAP v5 and v6.

Does the same thing happen if you do not calibrate the complex data?

Yes, same result:

And how about without calibration but with ESD? (the recommendation is to use ESD whenever possible).

Again, same result.

have you tried to select nearest neighbor resampling in the backgeocoding step? I remember that this had an effect once but cannot find the topic at the moment.

1 Like

This does seems to have fixed the issue, I will run it on the complete workflow and report back to you.
Thanks for the support,
Thijs

1 Like

Nearest neighbour fixes it? @jun_lu @lveci do the interpolators deramp the data appropriately?

I don’t think there was multilook in this graph?

Dear all,
After investigating the mentioned solution (S1 SLC Slave Intensity "oscillation" effect after Orb_Cal_Back_ESD_Deb), the following issue occured:

Though it worked for the slave of the slave-master pair mentioned in the initial post (S1 SLC Slave Intensity "oscillation" effect after Orb_Cal_Back_ESD_Deb),
the coherence had a different issue:
image

Here we see strange vertical bands in the coherence. The slave is fixed though.

It did work as a work around for a different pair where the oscillation effect previously occurred, as shown in the attached pdf.

Maybe you have a suggestion what would be the reason for these effects in order to pick the correct method?

Regards,
Thijs

Report_differences_resampling_slave_coherence_oscilation_effect.pdf (2.8 MB)

Thank you for the report Thijs, we will investigate the matter. @jun_lu @lveci @mfitrzyk

Thank you Marcus, this is really affecting an important service we use for the Charter and for the GEP Platform. @jun_lu @lveci @mfitrzyk thank you to you all for investigating the issue.

Jolanda, can you provide us with the graph + an image pair that recreates the issue?

Hey Marcus,

An image pair you can use for re-construction of the ocillation effect is this one:
Master: S1A_IW_SLC__1SDV_20180307T060825_20180307T060852_020905_023DDA_32C4
Slave: S1B_IW_SLC__1SDV_20180301T060738_20180301T060805_009834_011C88_6C27

The complete processing chain is:

  1. Input SLC splitting in sub-swaths
  2. Apply orbits, calibration, back geocoding, enhanced spectral diversity
  3. Backscatter debursting
  4. Merge, Multilooking, Terrain Correction

So far we have discovered that (S1 SLC Slave Intensity "oscillation" effect after Orb_Cal_Back_ESD_Deb) the back geo-coding step is responsible for the “Oscilation” effect in the slave. This occurs when the Dem resampling method is Bicubic interpolation and the Resampling type Bysinc 5 point interpolation. However, when we chose the Nearest Neighbour re-sampling method, the slave was clear but another effect occurred after calculating the coherence, as can also be seen in the report.

I attached the graphs used for the (1) Splitting of the images, (2) Apply orbits, calibration, back geocoding, enhanced spectral diversity (3) Backscatter debursting and (4) Merge, Multilooking, Terrain Correction

I hope you are able to reproduce the error, and shed some light on how to fix it.
Let me know if something is unclear.

Regards,
Thijs

4_merge_multilook_terrainCorrection.xml (5.3 KB)
3_deburst.xml (883 Bytes)
3_coherence_deburst.xml (1.4 KB)
2_orbit_calibration_backGeocoding_enhancedSpectralDiversity.xml (5.4 KB)
1_inputSplitting.xml (2.6 KB)