Border resampling artifacts in Range-Doppler Terrain Correction

[lnicola]

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.

[cpegel]

I have also noticed this problem before. Both in Ellipsoid Correction and Multilooking:

Here’s a subset of a S1A IW scene containing a burst transition along the border, without any processing:

After Multilooking with 4 looks in range and azimuth:

(Interestingly only one of the bursts seems to be affected here.)

And again, the original subset after Ellipsoid Correction (Geolocation-Grid):

Here the complete border is affected.

[cpegel]

Note that for the boundary between subsequent acquisitions in the same track, this should not happen when you apply S-1 Slice Assembly first. Have a look at the first steps of this tutorial.

[diana_harosa]

@jun_lu can you have a look at this?
Thanks

[jun_lu]

I don’t think it was caused by the noData value. Could you run the terrain correction again and unselect the “Mask out areas without elevation” option? Then you will see that dark edge is part of the sea. When we mask out the sea area using DEM, we mask out pixels with 0 elevation. However, DEM is not very accurate at the boundary of sea and land, and the elevations for pixels at the boundary are not always 0. There are always some pixels at the boundary which are not properly masked out. That’s why we see dark pixels at the boundary.

[lnicola]

Thanks for the suggestion. I tried, but I still see dark pixels around the edges, and not near the sea:

The DEM looks fine, though:

[cpegel]

Are there any updates on this? It is obviously not related to the land water boundary but to the boundary of the SAR acquisition.