After subtracting the thermal noise of a Sentinel-1 product, the resulting intensity can become negative (if the received power is below the noise level). According to Eq. 1 in the “Thermal Denoising of Products Generated by the S-1 IPF” document, such values should be clipped to “0”. That results in a couple of impractical consequences, e.g. when converting such a value to dB (-Inf).
In the SNAP operator for Thermal Noise Removal, this does not occur, because in this case instead of clipping to 0, a floor value of 0.01234567890000f is assigned. Still, the code itself makes reference to the exact same equation in the official document, however without justifying why instead of clipping to 0, a floor value is used.
I’d like to find out what the reasoning behind this approach is and why it seems to conflict with official guidelines. In Orfeo Toolbox, those pixels become true 0 while in SNAP they get some low value, so the result is inconsistency in output products.
Thanks for replying Marcus. Do you know what the floor value is based on? In fact, after calibration and probably terrain correction, the pixels below the noise value don’t have the same floor value anymore but something else. Values seem to be able to go even <-50 dB, so they’re not constant and equal to the floor value.
Interpolation changes pixel-values unless you choose Nearest Neighbour. Why is important for you to track these pixels afterwards - what is the use-case?
@junlu@lveci do you remember why the floor-value is set to its present value?
The importance is that I’m having discussions about the usefulness of SNAP-derived backscatter values below the noise level which seem to give the impressions that this is real data, while it’s actually some floor value being altered by other preprocessing steps. I’d like to respond with some sound arguments why the official guidelines of clipping to “0” are not followed by SNAP. As we agree, it is more practical to avoid 0 values, but if this is the only argument, it’s hard to make the point compared to e.g. Orfeo Toolbox that outputs 0 values, resulting in “no data” in dB-converted time series.
I don’t think those pixel values can be classified as “no data”, on the contrary it is valid information that the backscatter from those pixels is zero (=under the noise-floor). This is different from “no data” caused by radar shadow - there we have no information which kind of scatterers are in the shadowed area.
Ok so the code seems to put negative backscatter to the floor value of 0.01234567890000. Everything below the noise level will get this value (and the noise level itself varies per pixel based on the noise vectors, right?). So that floor value is about -19 dB which is odd, as it is not the NESZ of -22dB (although I’m not sure I may consider this as a logical floor value), nor even close to the minimum observed backscatter values in the output products (which can easily go to -50 dB and even lower).
So I’m still having a hard time connecting this fixed “practical floor value” to the values which are actually in the output backscatter intensities produced by SNAP. Is this all related to calibration and terrain correction which is done on top of the fixed floor value?
@mengdahl@lveci so it seems in fact the most recent version of the thermal noise removal code does not assign the floor value to values below noise, but only if the DN itself is 0 (does that even happen?). If not, it takes the original DN value (effectively disabling the noise removal).
So my question still stands: what is this choice based on? It still refers to the ESA document, but that one states you should put the negative values (backscatter below the noise level) to 0 (instead of disabling noise removal which is what SNAP does now).