Was this fix also ported to the 7.0 version? We just processed a few scenes with a standard workflow and see nodata (0) values in areas with low backscatter.
Our workflow is based on the pyroSAR framework:
ThermalNoiseRemoval
Apply-Orbit-File, Calibration, and Multilook operators
Terrain-Flattening
Terrain-Correction
We didn’t do any further investigation (yet), but our results with version 7.0 look exactly like the ones above.
Could it be that these pixels are just zero and the no-data value (0) simply has to be removed?
If they really have a Gamma0 of zero, then how are we supposed to tell them apart from the pixels outside of the swath, which are also zero? As mentioned above, zero seems to be a terrible choice for the nodata value if we can have “data” pixels of the same value.
I agree. Was it different before SNAP 7.0?
It’s been a while since I experimented with this. The fix from earlier in this tread only resulted in none of the “valid” pixels actually becoming true zero, which made sure that the 0-pixels were definitely no-data. The first thing I did after running SNAP is changing all 0-values to a better no-data value choice (like -9999).
But if what you say is true, that there’s still “valid” real 0-pixels, then you’re right and you can’t distinguish these from true no-data (e.g. outside swath) as long as the no-data value choice remains 0.
I’m also not sure if one of the earlier suggestions of adding a very small number to 0 would help, as it might just be that this gets either added to all real no-data pixels as well, or not even to the valid 0-data pixels (which SNAP now considers no-data as soon as they become true 0).
I keep urging to NOT take a no-data value that is perfectly within the valid range. But that issue hasn’t been moving for a long time…