Terrain-Flattening of ascending Sentinel-1 images leaves residual terrain information.
SAR-Simulation of ascending Sentinel-1 images has shift between image and simulation products.
The series of tests I performed to confirm the computation error have included S1A and S1B, ascending and descending passes, several different vintages of data: 2015-2022, North and South, and East and West hemispheres. I evaluated near and far range areas of the images: different incidence angles. All images were updated with POEORBs.
I observed shifts between Intensity and Simulated_Intensity products, and inadequate flattening for ascending pass images. The shift between the intensity and SAR-Simulation ascending products appeared to be about one pixel and line. I ran a series of SAR-Simulation and Terrain-Flattening tests with Copernicus GLO30 DEMs shifted in 1/2 pixel increments east and south. I visually assessed the registration between the Intensity and Simulated_Intensity products, and quality of Terrain-Flattening using the different shifted DEMs. Shifting the DEM by 1 pixel east and 1/2 pixel south produced the ~best results. Quantitative results comparing the standard deviations of terrain flattened images using different shifted DEMs confirms my visual assessment. I cannot detect a Terrain-Flattening or SAR-Simulation error in descending pass Sentinel-1 imagery, but that computation could have subpixel errors less than easily observable: <1/2 pixel. Similarly the exact DEM shift required for ascending pass images is probably not exactly 1 pixel east and 1/2 pixel south for the 30m DEMs: +0.00027777777777, -0.00013888888888 degrees longitude, latitude.
A temporary workaround for this error is to shift SRTM and Copernicus 30m DEMs used for Terrain-Flattening and SAR-Simulation of ascending pass imagery one pixel east and 1/2 pixel south. This can be done using External DEM, and adjusting the DEM georeferencing using gdal_edit.py -a_ullr .
NOTE: The DEMs used for Terrain-Correction do not require this shift. @jun_lu
Additional information: I only tested Terrain Flattening with External DEM because of the TF artifact issue with auto downloaded Copernicus or SRTM DEMs. My tests were on CentOS 7, and several versions of SNAP: 7.0.2, 8.0.3, and 8.0.9, which all returned the same results.
I now have compared Terrain Flattening and SAR-Simulation products produced with both External DEM and autodownloaded Copernicus DEMs. The autodownloaded DEMs result in the TF issue noted above, but sufficient information is visible that suggests the SAR-Simulation registration to the image, and the qualtity of TF are different than when using External DEM. It was entirely coincidental that use of External DEM for SAR-Sim and TF of descending passes appeared aligned/correct, and that only ascending passes required the DEM shift.
@jun_lu If gdalbuildvrt with the default nearest resampling is used with an extent defined by -te, this can introduce a subpixel shift in an image. I was thinking SNAP might use gdalbuildvrt to combine the autodownloaded DEM tiles. We have encountered the subpixel shift effect ourselves.
@johntruckenbrodt That is exactly it. In my conversations with Frank Warmerdam, father of GDAL, he said gdalbuildvrt works exactly as requested, providing an output file with the exact extents specified. But when using -r nearest" which is the default, you incur a pixel grid shift to fit into the new extent, unless the new grid is an exact integer pixel shift from the source. In your link the vrt file that is created with the extent has the default nearest resampling to the new grid already applied when read by gdalwarp. It makes no difference that gdalwarp is using bilinear. If gdalbuildvrt included “-r bilinear” or other interpolative resampling you would not see that effect. You really cannot shift a pixel grid by a subpixel with nearest, without shifting the image relative to the source. But I warn about indiscriminately using repetitive interpolative resampling on data, which will result in some degradation. You can avoid the pixel shift by using gdal_translate -projwin, which will clip to the closest pixel without the shift, but your extents will not be exact.