We have a processing chain that processes S1 SLC images. A part of the chain is composed by the following steps:
Input SLC splitting in sub-swaths
Apply orbits, calibration, back geocoding, enhanced spectral diversity
Backscattering debursting
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.
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
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.
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.
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.
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:
Input SLC splitting in sub-swaths
Apply orbits, calibration, back geocoding, enhanced spectral diversity
Backscatter debursting
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.
