Radiometric calibration S1 – 3rd swath

I’ve coregistered the following products w.r.t. to a single master:

If I then compute the standard deviation of the amplitude (per pixel along the time dimension), it seems the third swath has a radiometric issue. In particular, the amplitudes vary a lot, as compared with swath one and two.

Here’s a plot of the standard deviation. Black means the amplitude varies significantly.


Interesting, can you check whether something changed at one point in time or not for that swath?

Have you used the “stddev()” function from the SNAP toolbox?

I have observed similar issues. I suspect there are some raster count issues in the function.

Here’s a plot of the mean amplitude per image as a function of time for one of the black patches:

There’s a clear slump on 10-Nov-2015.

Hi, I used my own stddev function.

But then that plot shows that the IW3 swath for the 10-Nov-2015 image was corrupt, no?

1 Like

Make sure you avoid using no-values.

Additionally when using own stddev() make sure it has the correct raster count/location, considering there might be data missing it could solve the problem. As for the native stddev() function of the SNAP it has hard time differentiating how many values are at the pixel, it rather takes the amount of all acquisitions in the whole area regardless of no-data-values.

Raster count (iterated over all bands):
if $band <= 0.0005 then 0.0 + $previous_raster_count else 1.0 + $previous_raster_count

stddev function iteration (note that the values will be as good as your average):
if $band <=0.0005 then $previous_stddev else sqrt(( pow($previous_stddev*($previous_raster_count-1), 2)+pow($band-average,2)) / $previous_raster_count )

This one should work properly.

Hi Esteban,

Your problem is unexpected - it is possible that there was an issue when extracting/downloading the product. I suggest you check the size of the 6 measurement tiff files (in the product measurement folder) - they should be the same as given below:

1144762256 Jan 28 13:37 s1a-iw1-slc-vh-20151110t181814-20151110t181839-008546-00c1b3-001.tiff
1144762256 Jan 28 13:37 s1a-iw1-slc-vv-20151110t181814-20151110t181839-008546-00c1b3-004.tiff
1365928760 Jan 28 13:37 s1a-iw2-slc-vh-20151110t181812-20151110t181837-008546-00c1b3-002.tiff
1365928760 Jan 28 13:38 s1a-iw2-slc-vv-20151110t181812-20151110t181837-008546-00c1b3-005.tiff
1324940168 Jan 28 13:38 s1a-iw3-slc-vh-20151110t181813-20151110t181838-008546-00c1b3-003.tiff
1324940168 Jan 28 13:38 s1a-iw3-slc-vv-20151110t181813-20151110t181838-008546-00c1b3-006.tiff

I suspect one of the IW3 tiff files is much smaller than above. If this is the case, I suggest you try to unzip again or download again.


Hi Peter,

I’ve just checked. I’m getting a bad CRC when unzipping the file. I think I missed this because I’m working with the zipped product.

inflating: S1A_IW_SLC__1SDV_20151110T181812_20151110T181839_008546_00C1B3_8BF0.SAFE/measurement/s1a-iw3-slc-vv-20151110t181813-20151110t181838-008546-00c1b3-006.tiff   bad CRC 617be33e  (should be db7719e8)

I think this problem should get flagged by the SNAP product reader.

Thanks for your help! Good catch. I will re-download.



1 Like

Could you try again with the new update 2.0.2 The reader has been updated to try to detect this. Also, the product library scan has an option to check for bad CRCs in Zips.