Speckle Filter sets 0 where the intensity is negative

Hi everybody,

Since SNAP 10 update, my workflow to create despeckled images fails, at least for Sentinel-1 and PAZ data. This workflow worked like a charm with SNAP 9.0. I create first an orthorectified stack saved on disk as a GeoTiff (compression LZW, predictor = 1). I then open this file and apply the following graph (see sar_despeckle_default.xml below) with GPT.

With any filter stated in this graph (tested with Refined Lee, Lee Sigma and Median), negative values from my orthorectified data are set to 0 (which is nodata) when filtered. Is this a bug ? Is there any known workaround ?

sar_despeckle_default.xml (1.2 KB)

Original orthorectified data:

With speckle filtered data (DSPK) as an overlay:

You see in the colormap of the DSPK band that values don’t go below 1 when for native data it goes to -46.

For another example:


Here only GeoTiffs are shown, but it is also the case with BEAM-DIMAP files.

This is the case on both Linux (in a docker) and Windows.

@djagula, can you help?

1 Like

I think it is a problem in the GeoTiff reader and not a problem in the speckle filter. If you open the GeoTiff file in SNAP, you are probably asked to select a reader: GeoTiff (GDAL) or GeoTiff data product. For now please select GeoTiff data product to avoid the issue. A JIRA ticket ([SNAP-3796] - JIRA) has been created to track the issue and we will look into it. Thank you.

1 Like

Thanks for information

Your starting-point is incorrect as speckle-filtering should be performed in radar geometry and therefore before orthorectification.

I disagree, it depends on what you want to achieve :slight_smile:

On a strict point of view of minimizing the loss of information, I would strongly recommend your approach!
But in my workflow, where computation time is essential, this approximation is OK as I don’t want to orthorectify twice the despeckled and non-despeckled bands. So I am OK to “blur” my already orthorectified band, with the cost of an additional loss of information :wink:

Thanks, I will test this as soon as I will come back to work :slight_smile:

If you want to “despeckle” after orthorectification you should use some truly generic filter like mean or median since a) they are faster and b) you are not misapplying filters made for SAR data.

1 Like

Dear @mengdahl,

Could you explain why these filters are SAR-specific data ?

From what I could read in the literature, it seems it’s not.
For example for Lee Filter’s definition that can be found here: Lee's local statistics filter, it doesn’t seems to care about the type of image we have.

Moreover, from ENVI documentation, I can read that :

Lee filtering is a standard deviation-based (sigma) filter that filters data based on statistics calculated within individual filter windows. Unlike a typical low-pass smoothing filter, the Lee filter and other similar sigma filters preserve image sharpness and detail while suppressing noise. The filtered pixel is replaced by a value calculated using the surrounding pixels.

Maybe the SNAP’s implementation is, however.
Could you develop the points you made before ?
Thanks a lot :slight_smile:

If you check the SNAP Online help you’ll see that the implemented filter is the Refined Lee filter that is designed for SAR images:

https://step.esa.int/main/wp-content/help/?version=10.0.0&helpid=SpeckleFilterOp

ps. Always check the SNAP help and let us know if important information is missing :wink:

I’m sorry but I don’t see where in this page it is said that I cannot use the despeckle filters on orthorectified SAR data :sweat_smile:

1 Like

Specifying the format name from default to GeoTIFF-BigTIFF is a good workaround :+1:

<node id="Read">
    <operator>Read</operator>
    <sources/>
    <parameters class="com.bc.ceres.binding.dom.XppDomElement">
      <file>${file}</file>
      <formatName>GeoTIFF-BigTIFF</formatName>
    </parameters>
  </node>

Without any formatName:

With GeoTIFF-BigTIFF:

1 Like

Well, that is a common property of SAR speckle-filters.