Calibration and thermal noise removal

Hi all,

I’ve notice that after applying calibration beta nought and thermal noise removal some values equal to 1000 appear on the image. I guest this are value under the noise floor? is it right? why they were set to 1000? Can someone provide me more information?



Ps SNAP 2.0 last update, images S1A_IW_GRDH_1SDV_20150914T170628_20150914T170656_007714_00AB66_3E66

I am struggling with this point too. Thermal noise removal (TMR) sets the along range border stripe values to 1000 in GRD images. After calibration, this becomes 0.00225 (which is -26.4 dB). This does not seems to be the noise floor, though, because I have VH values being 1000 or lower (i.e. lower than -26.4 dB). If I skip TMR and calibrate, values are typically < 0.00004 (-44 dB).

There is a reference in "S1 GRD Border Noise Removal to
[1] Masking “No-value” Pixels on GRD Products generated by the Sentinel-1 ESA IPF, Reference MPC-0243, Issue 1.0, Date 2015, June 25.

but since that is unfindable, there is not much we know about the choice of 1000.


Thanks for the answer. To be honest this make me a little bit more confused especially for what concern the application of the thermal noise removal: it has to be performed before or after the calibration?

I applied it after the calibration following somehow the graph contained in snap under the name Sentinel1SLCtoGRDGraph. This is somehow also supported from the help of the thermal noise removal where you can read : “The values in the de-noise LUT, provided in linear power, can be used to derive calibrated noise profiles matching the calibrated GRD data.”

Anyway if the value it outputs for measures under the noise floor is 1000 maybe it makes more sense applying it before the calibration.

Nonetheless, Snap allows you to apply it before or after the calibration. Is there a proper way?

Btw the workaround I am doing is setting all the values equal to 1000 to the minimum of the considered image…but definitely it would be important read the document you cited. Can the developers help us?


The noise removal should be done before calibration. The value of 1000 was picked to avoid them becoming no data value. Everywhere in the toolbox we need to move away from using 0 as the default no data value. This is legacy from when ERS and Envisat used the value in the product.


Thanks for the clarification. it is very much appreciated. BTW, is it possible to get the document Guido cited (we do not find it around):

[1] Masking “No-value” Pixels on GRD Products generated by the Sentinel-1 ESA IPF, Reference MPC-0243, Issue 1.0, Date 2015, June 25.

MPC-0243 is here:
It refers to S1TBX’s ‘S-1 Remove GRD Border Noise’ operator, and not to thermal noise removal.

Some questions:
Why was 1000 chosen, and not 1 for instance?

‘S-1 Remove GRD Border Noise’ can classify some pixels as NODATA. This is clear to me.
Can any other operator also convert pixels to NODATA? The question is restricted to operators applied to GRD images (thermal noise removal, calibration, TC…)

This issue causes real headaches when working in Google Earth Engine.

My use case is to mosaic many images (globally).

In EE, the images there are pre-processed with:

  1. Apply orbit file (using restituted orbits)
  2. Thermal noise removal
  3. Radiometric calibration
  4. Terrain correction (orthorectification)
    Since there are two more steps after TNR that value of 1000 (?) gets modified and becomes really hard to filter out. In the images I’m working with, things that are obviously edge strips go up to -15 dB in the HH band. Now if I mask out everything below -15 dB that also catches most of the water bodies and a few land features. This occurs in a lot of images; for instance at the south and west edges of the image with ID S1A_EW_GRDH_1SDH_20141003T201429_20141003T201533_002670_002F98_6EFE. I’m not completely sure that it has to do with the TNR, could be something else.

What’s the reason this is implemented with setting these regions to a particular value and not just set it to a no-data flag which remains no-data throughout subsequent calculations?

Are there any plans to address this in the future? Or do you know of a good way to deal with it?


Does it matter in which order start the S1 processing with either “Thermal Noise Removal” or “Apply Orbit File”?