Border noise error for SLC

Microwave Toolbox
#1

Hi everyone, this problem seems well documented for GRD’s, but I have the issue in my SLC chain.

SLC chain goes: image

The border error initially appears as a line of low value pixels around the edge, but after the speckle filter these get pulled out into icicles. values are in the range of 0 to 0.0001. Image values are > 0.003 (for the C11 band of the C2 matrix)

I have written an elaborate procedure to get rid of it (threshholding values that >= 0.0001 ->> convert to mask ->> polgonise mask ->> clip original image ) as haven’t found a tool (grd-border-error tool is for GRD’s only!).

Heres an image of the border error:

image
image.png809×740 28.9 KB

Anyone have any ideas as don’t want to reinvent the wheel!
Thanks,
Ryan

#2

why not just subset 50 pixels in to cut out the garbage on the edge?

#3

BTW it’s inefficient to use terrain correction and terrain flattening in the same graph. In the future we’ll probably revamp the current implementation so that terrain flattening becomes part of terrain correction, but currently it’s better to keep these steps in separate graphs for performance reasons.

1 Like
#4

The annotation files for S1 SLC products actually provide the coordinate information to separate valid from non-valid pixels. This is given at burst level.

Look at section 6.3.1.6 Swath Timing Data Set Record (especially parameters firstValidSample and lastValidSample) in the Sentinel-1 Product Specification:
https://sentinel.esa.int/documents/247904/1877131/Sentinel-1-Product-Specification

I don’t know whether this information is used in any of SNAP’s operators. I assume there is a way to write some of your own code (in snappy maybe?) and then incorporate it in a graph.

#5

Dear all,

I confirm the css statement.
The TOPS SLC do contain information first/lastValidSample that gives the good portion of the burst. By using this you will remove some good pixels in the overlap area.
Since the processor version IPF 290 (march 18) we are actually using this information to clean the dirty pixel on the GRD (hence since that date the border noise for GRD is not necessary anymore).

Nuno Miranda
S-1 Data Quality Manager

2 Likes
#6

Hi all, thanks for the excellent replies. Ill try and handle them in order.
@lveci, id need to discriminate between valid pixels as mentioned in other comments. This is because the valid pixels are often diagonal to the raster edge, so cropping the border is equivalent to ‘squaring a photo’ and will drastically reduce the image footprint.
@mengdahl that is very useful to know. Unfortunately for me, it will be a pain as i was planning on adding a subset operation to the end, and because snap very cleverly operates on the subset pixels only (even if the subset operation is put last) it means i will have to rethink my optimisation. Perhaps i will just put the subset after the TF, write to file and then implement the TC.
@css thanks thats an excellent tip. @nuno.miranda do you know if this tool wil be extended to SLC? If so that would be great as it would save me writing a less than perfect solution.
Thanks everyone,
Ryan