Could you provide the product names and I’ll try to reproduce it? Thanks
Hello,
Of course:
The product that is giving me this error is:
S1A_IW_SLC__1SDV_20160902T051117_20160902T051144_012869_014526_DFB4
From this product this are the pre-steps I use before the Terrain Flattening
- Split to and use only IW2 VV
- Apply Orbit Files
- Deburst
- Subset to obtain a smaller area of interest
Coordinates: 42.793,13.199 42.608,13.341 - Radiometric Calibration for beta naugh
- Terrain Flatteing STRM1Sec Bilinar Intepolation
I think you need to multilook (15x4) the image first before applying TF with SRTM 1s DEM. This is to make sure that the DEM resolution is higher than that of the image.
this sometimes appears as an error when the two resolutions are different. But I don’t think it explains the holes in the image after (predominantly successful) terrain flattening.
Hello,
Yes, plus on previous dates of the same area, the Terrain Flattening was succesful too. I hope @lveci can replicate the error, as the DEM is produced with no issues.
The problem occurs with the ‘non-regrid’ method. We plan to deprecate this method in favour of re-gridding. Currently however, the regrid method forces you to multilook excessively to the point that both range and azimuth resolution are less than the DEM.
1 Like
dear @lveciI
I have images from TerraSAR 3m resolution And would like to apply terrain flattening and then Terrain Correction. Which DEM will do the job better? 3 or 1 sec? Kind Regards
Ideally the DEM should have the same resolution as your SAR-data. Use the better SRTM and see if the result is good enough (you’ll have a factor of ten difference in resolution…)
Dear @IVECI
I have a theoretical question. I have done coherence estimation analysis and compared the coherence between pre and post earthquake in Italy.
I used Sentinel1A data and for my pre-processing I used the SRTM1 DEM. This DEM is 30m resolution. For the same area today I got a 10m DEM.
Now my question is if this difference in DEM’s will produce different results in coherence as well as for example backscattering values?
Thank you
What is the recommended solution for the issue of black blocks in the middle of terrain-flattened Sentinel-1 images? Excessive multilooking is not a solution. I have tested 5m resolution DEMs with ‘non-regrid’ which fails with null pointer exception. There is no change with version 6.0. I am working with S1A_IW_GRDH_1SSV_20160526T194932_20160526T195003_011434_011670_F15D
Additional information: The minimal process is read-calibration-terrainflatten-write. Using various downloaded, or my DEM achieves a similar result. DEMs do not have zeros or fill values. 10 of the 47 S1A, relative orbit 162, images over the mountains near Port Moresby, have large black blocks in the same or similar areas of the terrain-flattened images. Most of the others have no defects, except a few that contain much smaller defects near shadow areas. Below is a small subset of the 20160526 flattened image.
Regards.
1 Like
some black areas are introduced when 0 is set as a NoData value in the Raster properties. If these zeroes are processed they are treated as NoData and sometimes get larger (when resampling is involved).
There are no NoData areas in our DEMs.
Don’t use the original method. It should only be ‘re-grid’. When processing a tile, snap retrieves the dem over the area that should cover the tile. With SAR and mountains, considerable overlap may be needed. The artifacts look like there wasn’t enough dem for that tile. We would need to increase the amount of dem overlap or make it a parameter.
I just tested the 6.0 release and found similar black holes, compared to 5.0 and 6.0 Beta, in the terrain flattened product for: S1A_IW_GRDH_1SSV_20160526T194932_20160526T195003_011434_011670_F15D
Luis suggested that the in memory DEM tiles might need to be increased in size. I think this could alternately be the result of not enough, or not the correct set, of in memory S1 tiles being loaded for some areas. Notice the left edge of these black areas follows the topography similar to the edge of the ortho images.
Another terrain-flattening black area effect, “edge-wedges”, that appears on the left and right side of some terrain flattened products is shown last below.
Mapping of some areas of New Guinea cannot be completed without a fix for this issue.
Left side of terrain flattened image:
Hi,
I am using SNAP 6.0 for processing S1A GRDH data and after terrain flattening my results are affected by artifacts too. Before doing the flattening there are just low intensity values located. After the flattening those areas are 0.
Similar posts:
http://forum.step.esa.int/t/artefacts-in-s1tbx-radiometric-terrain-flattening/397
http://forum.step.esa.int/t/terrain-flattening-and-converting-gamma0-to-sigma0/4864
The datasets I used are:
S1A_IW_GRDH_1SDV_20160829T054219_20160829T054244_012811_014333_61B5.SAFE
S1A_IW_GRDH_1SDV_20160302T054202_20160302T054227_010186_00F082_9C77.SAFE
Here are the processing steps:
- Remove-GRD-Border-Noise (I tried it without this step, but the results were the same)
- ThermalNoiseRemoval
- Apply-Orbit-File
- Calibration (beta naught)
- Terrain Flattening (SRTM 1 Sec HGT Auto Download; bicubic; Re-grid)
Figure 1: SRTM 1 sec
Figure 2: Dataset 20160302 after processing steps 1 to 5
Figure 3: Dataset 20160829 after processing steps 1 to 5
Figure 1: Dataset 20160302 after processing steps 1 to 4
Figure 2: Dataset 20160302 after processing steps 1 to 5 (SRTM 1sec)
Figure 3: Dataset 20160302 after processing steps 1 to 5 (SRTM 3sec): less artifacts than by using the 1sec SRTM
Thereafter I want to apply the following steps:
6. Range-Doppler Terrain Correction (SRTM 1 Sec HGT Auto Download; DEM: Bilinear Resampling; Image Resampling: Nearest Neighbour; 10m)
7. Create Stack (Resampling: None; Initial Offset: Orbit) of 10 datasets (8 x descending orbit 139; 2 x ascending orbit 88)
8. Subset
9. Multitemporal Speckle Filtering (NEST; 7x7)
10. Linear to dB
Do you have any ideas for solving this problem? I tested many combinations of the processing steps, but all results are affected. Do you need more information? After the preprocessing I am going to do a classification of tree species. which is why I want to reduce radiometric distortions. As I am using datasets of different orbits, terrain flattening should be an essential step.
Best regards
Have I overlooked something or does nobody have a solution?
Based on the idea by Small (2011), am I right that TF should be applicable to each pixel in the dataset without having artifacts?
I did another test for finding out what’s the problem with TF.
Dataset: S1A_IW_GRDH_1SDV_20160302T054202_20160302T054227_010186_00F082_9C77.SAFE.
I used SRTM 1Sec HGT (Auto Download) for downloading all relevant tiles, switched off the internet and renamed the files. Just one tile retained its name (N50E007). The location of the tiles is: "C:\Users\username\.snap\auxdata\dem\SRTM 1Sec HGT". Despite editing the folder paths ("C:\Program Files\snap\etc\snap.auxdata.properties"), an external DEM or the option SRTM 1Sec Grid are not working.
The figure in the lower left shows the result of TF using the replaced SRTM tiles. For N50E007 the TF was applied correctly (but artifacts are visible). For all other tiles the replaced ones are used, because new terrain effects occur after TF, but the black area artifacts are gone.
In the following figures the subset of my previous post is shown.
Figure 1: 1. Remove-GRD-Border-Noise -> 2. ThermalNoiseRemoval -> 3. Apply-Orbit-File -> 4. Calibration (beta naught)
Figure 2: 1. Remove-GRD-Border-Noise -> 2. ThermalNoiseRemoval -> 3. Apply-Orbit-File -> 4. Calibration (beta naught) -> TF (SRTM 1Sec; correct tiles) || Artifacts are visible
Figure 3: 1. Remove-GRD-Border-Noise -> 2. ThermalNoiseRemoval -> 3. Apply-Orbit-File -> 4. Calibration (beta naught) -> TF (SRTM 1Sec; replaced tiles) || Artifacts are NOT visible
For figure 3 the SRTM tile N49E006 was replaced by N49E007, whereby no artifacts occurred.
Same problem with TF here. Bad over mountainous areas.
SNAP 6.0.
S1A_IW_SLC__1SDV_20170119T172524_20170119T172551_014903_01850F_AA08.zip
TOPSAR-split-aply orbit-thermal noise-calibration to beta-terrain flatten (No regrid, bicubic interpolation, SRTM1 auto download.)
Regrid UNFLAGGED because with grid it simply makes processing takes too long (2min -> 4 hours)
Oh man, the artifacts are shadow areas. Sorry!
Shadow areas would not have straight line edges. I am guessing that those straight edges are the edges of missing DEM tiles in memory.