ICEYE calibration to sigma0

snap
1

Dear @Marco_EOM @ABraun ,

As far as I can tell, the process of calibrating to sigma0 involves thermal noise removal and speckle filtering. However, SNAP does not support ICEYE calibration to sigma0 because, I believe, the incidence angle is not available, and sigma0 is the radar cross section that accounts for the incidence angle derived from the meta data.

image
image541×545 37.5 KB

Any answer please. Thanks a lot.

2

The calibration process is defined by the satellite manufacturer/operator. Have you looked at their documentation?

3

Yes, I did, but I believe there is something amiss in this. First of all the thermal noise removal doesn’t support ICEYE in SNAP, then, as I shared in previous post the sigma0 requires incidence angle. In other words I think SNAP doesn’t support what is mentioned.

4

You are right, only the ICEYE SLC product is currently supported.

Products Supported

  • Sentinel-1 (IW, EW, SM SLC and GRD) are fully supported

  • ASAR (IMS, IMP, IMM, APP, APS, APM, WSM) are fully supported

  • ERS 1 & 2 products (SLC, IMP) are fully supported

  • Radarsat-2 products are fully supported

  • RCM products are fully supported

  • TerraSAR-X/TanDEM-X products

  • ALOS 1 and 2 products

  • Cosmo-Skymed products

  • Kompsat-5 products

  • PAZ products

  • RISAT-1 products

  • Iceye SLC products

  • Third party SAR missions may not be fully supported for all modes.

1 Like
5

Dear all,

So, If I understand well @mengdahl, radiometric calibration for Iceye GRD product is not supported?

In that case, why Iceye mention in the document you shared above, the following: “For amplitude scenes, a conversion to sigma0 has already been applied using the incidence angle calculated from the ellipsoid model.”
How should we understand this statement? And how should I interpret the ‘sigma0’ band that I get when I apply the SNAP ‘radiometric calibration’ operator with an ICEYE GRD product? (because I do get such sigma0 band as output…)

Thanks for the clarification

6

Well, if the product is “not supported” by the operator, the outputs cannot be trusted and arguably an error should be thrown. We should make sure sigma0 conversion with ellipsoid does not take place twice.
Perhaps @jun_lu could investigate?

1 Like
7

As an example, below are some values of the original amplitude and intensity of an ICEYE GRD product as well as the calculated sigma0:

image
image1920×651 241 KB

The values seem quite reasonable, although an extra sin(theta) in the calculation would be hard to notice

8

A JIRA ticket ([SNAP-3559] - JIRA) has been created to track the issue. We will look into it. Thank you for reporting the issue.

1 Like
9

Dear Sir,
Hope you’re doing very great.
I’d like to ask about the progress of this ticket.
Thanks a lot.
Merry Christmas and Happy New year 2024.

10

The issue has been fixed. The fix should be available in the next release. Thank you for pointing out the problem.

2 Likes
11

Thank you so much for your kind support. While the teams at ICEYE and Bayanat had different perspectives at the time, science is science, and the facts remain the same after almost a year.

1 Like