We have a quite standard processing chain (border noise removal, thermal noise removal, calibration to sigma0, terrain correction and linear to dB). We had some issues before already with the no data value in sentinel 1 data, which happened to be 0, a strange choice as it is within the physical possibilities, certainly if propagated as such into the dB backscatters. Anyway, we had our procedure of using gdal in the final geotiffs to put these to -9999. This worked reasonably well.
However, as of mid march onwards, with the new SAR processor in place and corresponding s1tbx updates, this does not work anymore. Apparently, the thermal noise removal procedure now introduces “-0.00123456” as no data value. Afterwards, Calibration transforms those pixels it into -1E-30, while the official no data value remains -0.00123456. This actually messes up pretty much everything. Two sorts of no data values are now in the image, both of which are very strange choices, and they are not correctly propagated. Converting to geotiff still does not produce NaN values in float32. This makes it very hard to handle the true no data pixels appropriately and these values are within valid range so it’s just dangerous to use them.
Has anyone experience with this and how to handle this? Frankly, it’s driving us crazy right now. Any hints are most welcome.
Not much activity here
In addition, we found another but related issue: apparently, the thermal noise removal function produces pixels with 0 backscatter after the March update. These are pixels that are supposed to have a valid positive value, but become 0 somewhere in the progress. This affects older images processed with the new toolbox as well.
0 backscatter cannot be converted to dB, because this becomes -Inf, which results in no-data. Initially, the GRD product also uses 0 as no data, but as explained above, this gets changed during the process…
Anyway, the current toolbox yields no-data pixels in regions such as still water surfaces, where backscatter is very low anyhow, but becomes zeros after thermal noise removal. @mengdahl or @lveci, maybe one of you could shed your light on these issues?
Thanks Luis,
if you have access to the Earth Engine forum, you could have a look at the following thread, where (at the bottom) I’ve made some analyses about this.
Dear @lveci, any updates on this? We’re kind of stuck at this point in the process of setting up our processing chain for the Belgian CGS because of these issues, and also the guys from Earth Engine are waiting any suggestions from your side.
it’s not all over the scene, it’s only some pixels, typically the ones with very low backscatter values. Where the previous version of the toolbox was doing fine here, resulting just in low dB backscatters, the new version sets the intensities to 0 after noise removal, resulting in no-data pixels when converted to dB. Applying the new version to images acquired before 13 March results in similar issues. It’s definitely toolbox related…
The situation is that the developer S1TBX went out of business in March this year, which is why at the present time bug fixing is very slow. We are taking corrective action to remedy the situation.
Hello, I am bumping this thread because I believe that this still may be an issue that I am also experiencing.
@mengdahl indicated in the Earth Engine users group
Blockquote Kristof, the 0/no-data issues in S1TBX were solved some time ago in a module-update to SNAP6. If you install 6.0 and apply all the available updates, it will work.
So I did just this. After updating snap from 6.0.0 to 6.0.3 and updating all the modules, I still am seeing NaNs over low intensity regions:
Product ID: S1A_IW_GRDH_1SDV_20180321T055027_20180321T055052_021109_02444F_007A
Most of the black dots in the have the value of NaN and this was projected to UTM.
The issue seems prevalent if I attempt to project the output to Auto UTM during the Terrain-Correction step. If I select WSG84 then there are hardly any NaN values over this lake and just one or two pixels observed in the river for this scene are NaN. However, when projecting to Auto UTM the NaN values are much more common.
Is it possible that there actually was an update that fixed this issue? It is possible there is something I am missing here.
indeed, I’ve also experienced that the issue is still there. Was planning to further document but haven’t had the time yet. Disbling NoData value is not the solution because (i) you cannot make any distinction between “truly 0” (whatever that may be) and e.g. “masked by border noise removal tool”. In addition, converting these 0-pixels to decibels results in -Inf which would result in no-data anyway. Looking into the code, there’s supposed to be a “floorValue” implemented for the thermal noise removal. I guess this floorValue should be put for those pixels, but somehow the code does not do this.
So indeed, still a standing issue.
I have no clue how this is related to the issue at hand. Really, it’s just single pixels becoming 0 after thermal noise removal (instead of some floorValue) which mess up everything. No resampling or interpolation involved in that step whatsoever.
So I’ve been having the same problem as well. I didn’t have this issue during preprocessing sometime last year but I have been having no data values which is weird… What to do? what to do?
