Did you apply TOPS Split and Deburst?
if you calibrate, you should select “complex output”. Besides that I would recommend to skip matrix generation and directly proceed to the Unsupervised Polarimetric Classification.
I noticed that multi-looking of SLC data can lead to stripes in some cases so I would skip this step as well.
Top: Original image of VV and VH
Bottom: Multi-Looked image of VV and VH
The following steps worked for me.
- TOPS Split
- TOPS Deburst
- Polarimetric Speckle filter (outputs C-matrix but that’s fine)
- Unsupervised Polarimetric Classification (Dual Wishart)
- Polarimetric Decomposition and H-Alpha Plane Generation
You see that S1 Dual Polarization is not ideal because it nearly doesn’t cover scattererest in Z3, Z5, Z6, and Z9.
How is this possible? That’s extremely strange. It seems to be related to the phase ramp due to the TOPSAR acquisition mode but, though you can see it in the I/Q image, the phase is not retained in the amplitude image .
Here below : i, log(intensity), q (from a multilooked SAR image)
you are right. The pattern should not persist in the multi-looked image.
I found that the difference is the selection of input bands:
Left: Intensity was selected (see below), right: no input band was selected.
Selection for the left image:
Only intensity bands remain in the product.
Selection for the right image:
Intensity and i+q remain in the product.
I tried to replicate your strange pattern with my images, given your indications, but cannot. First time I see that I can’t figure out what black magic happened there
Are each Intensity (VH and VV) touched by this ramp ?
yes, the pattern is in all bands:
Now I selected no input band and get different stripes regarding the number of looks:
Maybe some Azimuth-Range ratios are enhancing the patterns while others don’t.
The pattern there is totally normal for the i/q bands, with or without multilooking. I was meaning the intensity band. In my case I have the pattern in i/q bands, but in the intensity computation, the ramp vanishes
Or ar you meaning that you are using i and q bands to make RGB composition?
Yes, sure. But it is strange that after multi-looking it is introduced again.
My RGBs are made with intensities.
We need to check/update the implementation of multilooking, it’s from the early days of NEST and notice that it has has a disclaimer saying that for complex products it is done “without resampling”.
yes, I guessed that this is one of the reasons for the pattens above.
It says that about detection - we will check. Could someone post a graph + data products that replicate the problem?
My data was
- TOPS Split (IW2, burst 5 only)
- TOPS Deburst
- Multi-look with 4/1, 6/2 and 10/3 looks
I am seeing similar artefacts when multi-looking 4/1 is applied in various complex products sources at SNAP, including other platforms (TerraSAR). This seems to be an issue impacting more than one user.
I’ve raised the issue in JIRA:
For Crop classification what are the processing steps of Sentinel1 SLC data?
I am using multi temporal Sentinel1 SLC IW data for classifying crop types. And to process them in SNAP, i am using the following steps:
- Apply Orbit file
- Callibrate (output sigma band for VV and VH)
- Speckle filter (filter Gamma map (3/3))
- Terrain Correction
Can anybody confirm the steps to be correct and appropriate for crop classification. Thanks in advance.
For classification purposese, Sentinel-1 GRD data is sufficient. I see no point in downloading, debursting and merging SLC data, to be honest. If wou worked on GRD data you could simply skip the first step and directly apply the orbit file and calibrate to Sigma.
Multi-looking is also not advisable for GRD data because the data are already in ground range.
Did you see this: Radiometric & Geometric Correction Workflow
And you can working with subsets if you use GRD data…
sure, you can subset it at any time.