It seems the algorithm for “GRD Border Noise Removal” does not work properly over OCEAN areas.
I have already changed the threshold from 0.01 to 10 and the results are the same.
If the document “Masking “No-value” Pixels on GRD Products generated by the Sentinel-1 ESA IPF, Reference MPC-0243” were available, we could analyse better what is happening.
Anyone has a trick for it?
The border noise removal was intended to remove the garbage around the
edges of a product in particular to help with land mosaics. The SAR
Mosaic operator in SNAP doesn’t really need this because you can use the
feathering parameter to eliminate edge pixels. However, others were
using third party mosaicking tools which required the cleaner image.
Your application over ocean may not need this operator.
Thank you for your attention!
The Wind Estimator creates dumb values over the border (noise areas).
In my opinion, that’s why we need the Noise Border Removal working well over the ocean areas.
I believe that the “GRD border noise removal” was implemented from a TN I have written with the help of the S-1 Mission Performance Center Team.
@lveci please confirm.
We will open the TN such that you can see what we proposed. We will keep you updated once done.
In this TN, there is indeed section called limitations where we foresee issues for data over ocean.
Our understanding was that it was likely to happen for data with very low signal (e.g. low wind speed on cross-pol).
Could you please post the filename, an image or some numerical values such that we can better understand the issue.
S-1 Data Quality Manager
Thanks for publishing this TN.
FWIW, these “dirty” pixels can also be seen at far range and, in the first or last slice of a datatake, before or after the slice in azimuth time.
For instance, S1A_IW_GRDH_1SDH_20141029T180952_20141029T181015_003048_0037B8_5A11.SAFE shows dirty pixels at far range and after the end of IW3.
S1TBX’s ‘S-1 Remove GRD Border Noise’ seems to be applied in all four borders of the images. In the image above, it appears to do a good job in all borders.
An image in which ‘S-1 Remove GRD Border Noise’ as implemented in S1TBX does not work so well is:
In this image it classifies some valid pixels at far range as ‘no-value’.
I attach two screenshots with the original pre-‘border removal’ image and with the post-‘border removal’ image, for the HH pol.
- imagewidth = 10395
- the screenshots are around imageX=10270 imageY=5150
- dirty border pixels start at imageX=10349
- zero-valued border pixels start at imageX=10358
- after border removal, the ‘no-value’ pixels start at imageX=10266 in many of the lines
I use SNAP 3.0
pre-‘border removal’ HH image
post-‘border removal’ HH image (‘no-value’ pixels have a uniform grey colour)
I’ll have to revisit this. Some of it was to address products in 2014 where the noise vectors weren’t sufficient. It was primarily intended to clean things up for mosaicking where it didn’t matter if some pixels on the edge were made no data value.
the problem has not been solved is it correct ? I have the same problem with land scences. If i use the “S-1 Remove GRD Border Noise” Tool either I have the phenomenon raised by css or it remains a small black border ? Is there any workaround to remove the GRD Border Noise ?
You could subset the product
I have similar problems with stripes in SAR wind retrievals. It seems to be related to the way the image is taken. It is very present in EW images. It seems like the jumps can easily be about 1 dB, which is a lot in terms of wind retrieval.
Have you found a solution for this problem? Or do you know who is working on this?
This thread is probably not the best place to complain about deficiencies in Sentinel-1 products (this thread is rather a consequence of such deficiencies). The concept of “GRD border noise removal” comes from the fact that the product itself fails to clearly document the invalid areas (by assigning these areas to 0 and the valid areas to non-zero).
The “border noise” is composed of two problems: range and azimuth.
The range problem can be dealt with by subsetting as suggested by Luis above. I have exclude the first 1050 pixels at near range and the last 800 pixels at far range. This obviously throws away lots of good data.
The azimuth problem - as far as I have seen manifestations of it - appears only in the last scene of a data take (when e.g. they have decided to switch to EW mode for some incomprehensible reasons). This problem only affects the IW3 swath, which extends furthest in azimuth:
The azimuth problem cannot be addressed by subsetting blindly the last 100 lines or so, because then the normal (not the last one of a data take) scenes would create gaps between scenes. The “GRD border noise removal tool” could try to detect these last-of-data-take scenes via image analysis or simply using some catalogue data. A better way would be to correct the problem at the source in SAR processor. Obviously the reason for the problem is that the processor defines its output window too long at the end in azimuth. It does not have enough raw-data records for the last lines in IW3. If the SAR processor defined its output window shorter when processing the last scene of a data take, the azimuth “border noise” would disappear. In the case of the sample image above, some 50 lines at the end of the image would be sufficient. Maybe 100 lines could be adequate as a general safety margin against “azimuth border noise”.
The position of a slice in a data take can be found in the manifest.safe file (fields ‘sliceNumber’ and ‘totalSlices’). I believe the fields ‘sliceNumber’ and ‘sliceList’ in the annotation files contain the same information.
Thank you for your post of 4.1.2017.
I don’t quite understand how these sliceNumber and totalSlices tags can be used to address the problem at hand. If you meant the swathMerging tags (swathBounds in particular), that is related. I just checked these tags for the scene above. The last swathBounds block of IW3 gives 7651 for tag lastAzimuthLine. Line 7651 is the last line of the scene. So, these tags give the extent of image data in the product, not the extent of valid image data. Therefore these tags are of no value solving the “GRD border noise” issue in azimuth. I doubt they have any better value for the range problem.
PS. I noticed that the azimuth problem exists also at the first scene of a data take. In this case they have started the output window of IW1 too early.
Just for the record what I ended up doing with “GRD border noise”:
The algorithm is based on line and column averages of VV data (because that exists in both SDV and SSV, which are the most common data types):
- if any of the first 40 line averages is less than 20, mask out the first 160 lines.
- if any of the last 40 line averages is less than 20, mask out the last 160 lines.
- find (within the first 1100 columns) the first column where the column average is higher than 20. Mask out the first columns until this column and then 100 columns more.
- find (within the last 1100 columns) the last column where the column average is higher than 20. From the column 100 columns before (or “inside”) this column until the last column, mask out.
I operated on 2-by-2 averaged images, so the dimensions have been multiplied by 2 in the algorithm description above. As the threshold (20 in VV amplitude) is below the noise equivalent sigma-0 and because the algorithm operates on line and column averages, it seems to work also in sea areas. The down side is that a kilometer is wasted in range along both borders, and some part of this may be valid data. A margin of 0.5 … 1 km might also work in range masking. The margin in azimuth masking is academic because it only affects the beginning and end of a data take and even there only one sub-swath out of three.
I tested the algorithm with nine scenes, and it seems to work. At least it wasted slightly less data at swath borders than my previous version, where I masked out a constant distance at near range and another constant at far range. And it should save me from yet another surprise on how many non-valid pixels can be at far or near range.
‘sliceNumber’ and ‘sliceList’ can be used to identify whether a slice is the first or last one in a data take.
Of course a different issue is how to deal with the non-0 nodata pixels.