This is pretty hard to spot, but I think the resampling done by the Range-Doppler Terrain Correction operator is using 0 values for the missing pixels at the borders of the image. As an example, here is a Sentinel-1 product (
S1B_IW_SLC__1SDV_20180112T233610_20180112T233637_009144_0105DE_2B56.SAFE), with the following operators applied:
- Apply Orbit File (Sentinel Precise)
- S-1 Thermal Noise Removal
- Calibration (Sigma_0, VV only)
- S-1 TOPS Deburst
- Range-Doppler Terrain Correction (SRTM 1Sec HGT, bilinear interpolation, default spacing, around 14 m/px)
The output looks like this, pay attention to the darker edge at the border:
I suspect this happens because the resampler uses 0 for “no data” pixels and includes them in the computation, polluting the output. See e.g. slides 73-79 in http://www.cyto.purdue.edu/cdroms/micro2/content/education/wirth02.pdf for a discussion of some common approaches to the problem.
Interestingly, this seems to affect the “horizontal” borders more than the “vertical” ones:
Maybe there’s some extra masking applied to the vertical edges of the sub-swath (notice the ragged edge above)?
This may seem insignificant, but it’s quite apparent when compositing multiple Sentinel-1 products, like below:
One workaround would be to figure out the kernel size and mask pixels that are in the neighborhood of a no data pixel in the output, but it’s pretty annoying to deal with, and I haven’t checked how much overlap between different tracks (?) there is.