Thank you, we will look into it
Version 7.0 does not exhibit the artifacts I reported. I tested the same images for New Guinea, with Terrain-Flattening defaults. I can confirm https://senbox.atlassian.net/browse/SITBX-639 is fixed for my case reported above.
https://senbox.atlassian.net/browse/SITBX-540 is fixed in 7.0, but requires a high setting for Terrain-Flattening additionalOverlap=0.8, for the Andes test area. See my edit of that post above.
2 Likes
Using 7.x (currently 7.0.2) there are still saw tooth artifacts on the edge of the S1 image at the bottom right (~S 10.9, W 76.1) of the processed geocell subset, even with additionalOverlap set to 1.0 which is the maximum.
There appear to have been at least three separate issues related to black areas on Terrain-Flattened products:
-
Internal to the image there were black tiles (or partial tiles). Improvements to the tile overlap scheme in version 7.x was likely the resolution. Additional tile overlap of 0.0 or 0.1 produces the same result without the defects for my limited test set. 0.1 may still be recommended since there is only a little time/CPU overhead. I have tested many areas of high topography and this appears to have been completely fixed in version 7.0.2 and possibly a few earlier versions.
-
triangular black wedges at the edge of the subset area: left side and bottom of screenshot below.
subset=POLYGON(( -77.0270393 -9.9729607, -75.9727765 -9.9729607, -75.9727765 -11.0272235, -77.0270393 -11.0272235, -77.0270393 -9.9729607)) -
triangular black wedges on edge of Sentinel-1 scene: right side of image area below and enlargements below.
For #2 I found the artifact can be completely removed by increasing the additionalOverlap to 1.0, but this is at an expense of upto 10x time/CPU. However, autodownload SRTM with additionalOverlap=0.1 does not have the left edge wedge artifacts. I then tested a mosaicked superset DEM which did not have the artifact at additionalOverlap=0.0. Terrain-Flattening should not need substantial elevation coverage beyond the subset area. (subset area was coincident to the extent of the original external DEM). Terrain-Flattening should only need a limited region around the pixel to compute the slope and aspect and therefore flattening. I believe this should be fixed. But an acceptable work around is to make the external DEM used for Terrain-Flattening ~10 km larger than the subset on all sides. I do not know why the imagery additional overlap scheme (ie. varying from 0.0 to 1.0) would have any effect on this artifact since it appears directly related to the DEM coverage.
#3 is tough: Even at additionalOverlap=1.0 the artifact is not completely eliminated, and includes a huge performance penalty. The three enlargements of the right side of the Sentinel-1 terrain corrected image are at additionalOverlap= 0.0, 0.1, and 1.0. There is still some artifact visible at 1.0. This is the same with auto download SRTM or any of my external DEMs. My work around is to trim the edges of the images, which I do anyway to make all dates have coincident coverage for my multitemporal processing.
I suggest that the imagery tile overlap scheme is having difficulty at the edge of the input S1 scene (probably stepping off the input image?).
@jun_lu
1 Like
Thank you for the analysis s0sh0rt!
Latest Terrain-Flattening results with SNAP v8.0.8, S1TBX 8.0.5 show that use of Auto-Download DEMs should avoid most of the issues in my posts above over the last few years, except #3. Use of External DEMs requires a superset DEM much larger than the AOI.
Of most concern are the internal void areas that are present when using External DEMs (#1 in my Sep '19 post). It appears that the computation of Terrain-Flattening requires DEM far outside the AOI in high elevation areas. This is true for processing of areas in the Andes near Yerupajá 10°16′S 76°54′W (same tests in my Jun '19 and Sep '19 posts). My AOI is a 1 degree area, but to avoid holes requires use of an External DEM about 3x3 degrees. Increasing theTerrain-Flattening parameter additionalOverlap has little or no affect. This seems to indicate that to compute Terrain-Flattening the ray tracing is shooting past the mountain beyond the small DEM only covering the AOI. This is avoided by auto-downloading since the addition DEMs required are automatically downloaded for the computation. Below are two images zoomed on Yerupajá, first with the small DEM just slightly larger than the AOI, and second image is with a very large DEM 1 degree bigger than the AOI on all sides:
For #2, when using External DEMs, “edge of subset void wedges” can be avoided by either use of a superset DEM or the Terrain-Flattening parameter additionalOverlap . For this example (unprojected - no terrrain correction) I used additionalOverlap=1.0, which can increase processing/CPU time 4x, so the superset DEM is a better choice. The image below shows results of processing with three different DEMs in RGB:
Red - small DEM additionalOverlap=0.0
Green - small DEM additionalOverlap=1.0
Blue - superset DEM additionalOverlap=0.0
The cyan area shows both the superset and overlap=1.0 are complete, and overlap=0.0 is missing red. Auto-Download DEMs do not result in this issue.
#3 (again in my Sep '19 post): “Triangular black voids on edge of the Sentinel-1 image”. This affects both External and Auto-Download DEMs. Terrain-Flattening parameter additionalOverlap=1.0 has a small affect, but is probably not worth the additional processing and CPU time (~4x). The image below shows an area on the edge of the Sentinel-1 image processed with three different DEMs in RGB:
Red - Superset External DEM additionalOverlap=0.0
Green - Auto download SRTM additionalOverlap=0.0
Blue - Auto download SRTM additionalOverlap=1.0
I used the same data as the Sep '19 examples, except I removed Terrain-Correction from the graph:
S1B_IW_GRDH_1SSV_20161224T233307_20161224T233336_003544_006102_6BD0.zip
S1B_IW_GRDH_1SSV_20161224T233336_20161224T233401_003544_006102_5C8B.zip
External DEM ~= SRTM geocell s11w077
Hi, I was processing some time ago series of S-1 GRD images and it seemed to went smooth for the whole series. Just now I realized that one date out of hundreds has this issue with Terrain Flatenning (black lines and skewed). Is there a way to solve? I tried both with snappy and SNAP GUI, but I get same results. I don’t know why, since dates before and after (same area, same relative orbit) were correctly processed. Issue is with products:
S1B_IW_GRDH_1SDV_20200430T163307_20200430T163332_021376_028939_426C.SAFE
S1B_IW_GRDH_1SDV_20200430T163332_20200430T163357_021376_028939_F258.SAFE
Any help is appreciated. tnx
Your image defects appear to be caused by flaws in Copernicus processing or the sensing system, and not TerrainFlattening. You might try processing from SLC.