Sentinel 1 GRD gamma0 statistics differ from SNAP values

s1tbx Problem Reports
#7

@glemoine this is correct, but he stated that he conducted these steps after importing the GRD product.
Also, the data in the EO browser has these steps applied. I guess it is either the projection, the DEM or the resampling. Which target projection did you select for your data?

The EO browser seeems to display the data in the Web Mercator projection (EPSG:3785)

#8

It is quite a bit difficult to provide decent response by only having a screenshot.
Some quick info/comment:

  • EO Browser’s default configuration uses Copernicus DEM, the best available resolution (i.e. in Europe 10m, elsewhere 30m)
  • instead of “statistical info” it might be better to export the GeoTiff (ideally in the same projection as you use in SNAP);
  • the layer you have chosen does not include radiometric terrain correction step; one below does
  • I am not an expert in SNAP, but might it be that you are not using orthorectification step there at all (not mentioned in the steps)
#9

Thanks @ABraun and @gmilcinski for your replies. For your info, I am trying to see the peak value of gamma0 for a corner reflector, so even if the map projection is different, the peak value for the pixels on the right corner (shown in the image) in both (SNAP and EO) should be the same (just might have the shift in location). As you can see the corner reflector is clearly visible and I can find it clearly in both EO and SANP images with any map projection (if different which I don’t think so) and then find the pixel with the peak value. So, I don’t think the map projection here makes any problem.

As you suggested, I exported the GeoTiff and imported in SNAP to compare the values of gamma0 From EO, VV_linear gamma0 radiometric terrain corrected band, gamma0(peak) is 4.92 and is again different from SNAP. Any further help/tips please?

#10

I would suggest to take a look at these two discussions, which might address (part of) your problem:

Beyond this I do not have good ideas.
If you provide exact steps that you are doing in way that can easily be reproduced, we might ask some engineer to look into it, but cannot promise you when.

#11

I still do. According to this source bilinear resampling is applied during the Range Doppler Terrain Correction which leads to different pixel values if the map projection is not constant: https://docs.sentinel-hub.com/api/latest/data/sentinel-1-grd/#available-bands-and-data

Please try both 3857 and 4326 in SNAP to see how your pixel value changes.

Especially local peaks can drastically differ if the pixels are slightly shifted or rotated as a result of a different coordinate system. WGS84 is based on degrees, UTM or Web Mercator on metres.

#12

Anything that affects resampling will cause the “corner reflector” to have a different peak value. So, that includes whether you used the correct recipe (which needs terrain correction), the DEM, pixel spacing, projection, etc. Terrain flattening not, because it will no longer be gamma_0. Try comparing what recipe EO Browser applies and compare to your own. There is likely a difference.

1 Like
#13

Fully agree.

#14

Hi again,
Thanks for all replies. I think I got you @ABraun now and I agree that map projection can change slightly the results. As you suggested, I tried both 3785 and 4326 in SNAP using Copernicus 30 meter, bilinear interpolation. I could get the TC results for 4326 (WGS84) and unfortunately not for 3785. I don’t know why it doesn’t show any results although the processing worked and I didn’t get any error message (please see the screenshots). Any idea why?

You can see in the screenshots the steps I have taken including making the subset image. It is intersting to know the subset image size (suggested by @gmilcinski) can change the results. In this case what is the proper size for the subset image can be a different and new question. I am not sure that question has been asked or if you can advise me for the proper size for subset.

The steps: Apply Orb, thermal noise removal, calibrate, subset (lats: 60.596,60.5936; long: 17.255,17.262), and then TC Range doppler terrain correction (Copernicus 30 m, bilinear, WGS84). If these steps are correct and similar to the EO (which seems they are, not sure), then still gamma0 values (from SNAP and EO) are different. Maybe the subset step makes problem?
Thanks,
Faramarz

image
image1859×897 170 KB

image
image1448×905 106 KB

#15

I think I see a potential difference. The Gamma0 from EO Browser is different from how you calculated it (within Range Doppler Terrain Correction).

To get the terrain flattened Gamma0 as in EO Browser, please first calibrate to Beta0, then apply Radiometric Terrain Flattening (results in Gamma0). Then you can proceed with subset and TC.

#16

Thanks @ABraun for quick reply, In calibration stage, I get all gamma0, betta0 and sigma0, so perhaps it is already done(?). Do you mean I should just add one more step before the subset and that is Applying RTF?
Faramarz

#17

The terrain flattened Gamma0 (also used in the EO Browser) is different from the one in the calibration operator.

Please see the discussion here: S1 radiometric correction

#18

I see, thanks. So, I calibrated only for Beta0 and then tried to do RTF, but got a error message. please see the screen shot. Any suggestion to solve it? I have updated my SNAP and have the latest version.

image
image1609×789 44.9 KB

#19

Did you store your data as GeoTiff?

Please try SRTM instead.

#20

No, I didn’t store, just in RTF process I got that error.
I can not use SRTM because the location (Lat) is above 60 degrees. I tried with Aster DEM, it finished without any error, but I see an empty image (see the screenshot please). Perhaps ASter DEM is not good too for this location. Probably SNAP has problem with the Copernicus DEM and makes GEOtiffread error. What else do you suggest please?

image
image1501×830 33.1 KB

#21

This is possible.
You can download it manually then and use it as “External DEM”

1 Like
#22

OK, thanks.

#23

Some more points to add:

  • SAR processing is complex and it is almost impossible that two different systems would result in exactly the same values. Resampling is probably the main “culprit”, which depends on output resolution, subppixel alignment, DEM/EGM resampling/alignment then reprojections, etc.
  • There was a paper published recently comparing Sentinel Hub S1 CARD4L product and Google Earth Engine one. There were as well differences found (obviously), but within the limits of what was expected. And Sentinel Hub’s process seemed to produce more accurate values:

Dyke G., Rosenqvist A., Killough B., and Yuan F., 2021. Intercomparison of Sentinel-1 Datasets from Google Earth Engine and the Copernicus Sinergise Hub CARD4L Tool. International Geoscience and Remote Sensing Symp. (IGARSS’21). FR3.O-10.6.

I would have assumed that both SNAP and Sentinel Hub process produce correct results, you just need to take care that you use them consistently, e.g. either one or another, across your experiment.

2 Likes
#24

Hi
Have you take a look to this post Sentinel 1 GRD sigma0 calibration wrong output values. For me a part of the problem comes from the calibration step in SNAP.

#25

GEE processing workflow (which produces sigma_0 btw) is fully reproducable in SNAP (kind of logical, as it uses a known recipe). It does not do alignment. Alignment is indeed another sampling artefact that may cause differences in the output. Subsetting may have a similar effect, if the pixel spacing is not exactly aligned.

Using a standard processing recipe with an open source toolkit is not really complex at all.

I wonder how these IGARSS folks determine what is “more accurate” (but IGARSS stuff is usually not open).

Google Mercator is 3857, btw, not 3785.

#26

you are right, thank you for clarification.