Unable to view SM SLC product in SNAP

mrodger · September 14, 2020, 11:23am

I’m currently having trouble viewing the intensity bands of an SM SLC product.

After opening the product in SNAP and double clicking on one of the intensity bands, I get a completely grey screen as shown below:

No explicit error message appears.

I have tried moving the folder to a different location with a shorter path (as suggested here), but I get the same result.

I have also tested on a similar product but, again, I get the same result.

I’m starting to think it could be indicative of a memory limitation (as explained here), although my system currently has 16 GB of RAM.

I’d be grateful for any ideas on this issue.

Relevant information:

SNAP version 7.0.4

Product identifier (main): S1B_S6_SLC__1SDH_20170811T002548_20170811T002612_006885_00C1EA_9437

Product identifier (test): S1B_S6_SLC__1SDH_20170823T002549_20170823T002612_007060_00C6FB_1015

ABraun · September 14, 2020, 12:13pm

did you import the product as zip file or did you extract it first?

mrodger · September 14, 2020, 12:42pm

I’ve tried both opening the zip file as well as extracting then opening the manifest.safe file.

ABraun · September 14, 2020, 1:30pm

do you get image statistics for the data? Select one band (doesn’t have to be opened) and click this button:

mrodger · September 14, 2020, 1:38pm

It appears that I don’t:

ABraun · September 14, 2020, 3:18pm

I just downloaded your product and tested it on my machine. I can confirm that the product is somehow corrupt and cannot be displayed in SNAP. I was not able to load it in ERDAS Imagine either, so I suspect that the file structure has somehow changed.

I remember working with S1 SLC SM products in SNAP, so this was possible at a time.

mrodger · September 14, 2020, 3:28pm

Thank you for confirming this for me, much appreciated.

I’ll report these products to Copernicus EO Support.

ABraun · September 14, 2020, 3:33pm

this product works for me, for example: S1B_S6_SLC__1SDV_20190813T024210_20190813T024221_017561_021078_0113

mrodger · September 14, 2020, 4:00pm

I’m particularly interested in the coastline near Houston, TX as I’m trying to extract the dimensions of SAR ship detections.

I’ve processed the GRD version of the same SLC product I’m having trouble with, but due to signature blurring/smearing the dimensions are significantly overestimated.

My idea is to process and multilook the SLC product myself to see if I can get a better estimate of these dimensions.

There appears to be many products so hopefully it’s only a few which are corrupted:

ABraun · September 14, 2020, 4:02pm

have you checked if you can apply radiometric calibration first so maybe the Sigma0 product gets displayed correctly.
As an alternative you can use the Land/Sea mask operator to mask out land.

mrodger · September 14, 2020, 4:26pm

I’m able to apply radiometric calibration but unfortunately it produces the same result:

Same as above after applying a land mask.

I get an interesting result after importing the geotiff:

ghajduch · September 22, 2020, 12:42pm

I checked this product: S1B_S6_SLC__1SDH_20170811T002548_20170811T002612_006885_00C1EA_9437.SAFE

Yesterday it was not available (as archived) and I had to wait for unarchiving before completing the download today.
However, I tried to open it from another tool (neither Snap nor ERDAS) and it works fine.
I did not spotted issue with this product so far.

Maybe there was some kind of product corruption when you downloaded it first (during the initial unarchiving).
Could you please try to download it and open it again ?

mrodger · September 24, 2020, 5:16pm

I’ve re-downloaded the product from the archive but I still face the same issue.

I’ve also verified the download integrity using the MD5 checksum (as described here). As you can see the MD5 of the product at the source and on my system are identical:

I understand you used a different tool, but are you able to verify if the product opens in SNAP?

ghajduch · September 25, 2020, 7:46am

I peformed the following checks with GDAL:

First: generate an intensity image with gdal opening directly the Tiff image. This works. Thus the data contained in the tiff is fine.
Below a snapshot of the corresponding intensity image (generated through gdal) and displayed in QGIS.
Please notice that there are some saturation as the intensity was computed as integer instead of float, thus introducing saturations (just a quick check).

Second: generate an intensity image with gdal opening the product and selecting the dataset (on polarisation or the other). This fails as all values are then 0.
However I don’t know the level of support of StripMap SLC for the Sentinel-1 driver in Gdal.

I crossed checked with SNAP and I have the same status as yours.

When opening the S-1 product, the intensity is 0 for all bands.
When opening the geotiff, the values are fine (see snapshot below after removing of display of GCP).

I think that there is something not properly managed by GDAL and SNAP between the tiff and the manifest. But I don’t know what.
@ABraun: do you know if SNAP is using GDAL as a driver to read the data ?

ABraun · September 25, 2020, 8:00am

I have to pass this to the developers - @lveci @jun_lu Do yu have an explanation for this?

ghajduch · September 25, 2020, 8:20am

I saw this (here: https://step.esa.int/main/toolboxes/snap/)

I double checked:
My tools are using GDAL but not using the GDAL/Sentinel-1 driver.
However they access the tiff data through the GDAL/Tiff driver.

This looks like an issue in the GDAL/Sentinel-1 driver.