 # Faraday Rotation Angle estimative with SNAP

Dear users and developers,

I have adapted the algorithm for Faraday Rotation Angle estimative presented in the ANNEX C of Calibration_palsar_products_v13.pdf (151.9 KB) for using with “band math” of SNAP.
OBS: It should be great if the developers should implement such algorithm within next updates.

The matrix M (2x2) represents the quad-pol data in circular basis:

• M11_real = i_HH - q_VH - q_HV - i_VV

• M11_imag = q_HH + i_VH + i_HV - q_VV

• M12_real = - q_HH - i_VH + i_HV - q_VV

• M12_imag = i_HH - q_VH + q_HV + i_VV

• M21_real = - q_HH + i_VH - i_HV - q_VV

• M21_imag = i_HH + q_VH - q_HV + i_VV

• M22_real = - i_HH - q_VH - q_HV + i_VV

• M22_imag = - q_HH + i_VH + i_HV + q_VV

The FR estimative for each pixel:

• FR_angle = 0.25 * atan ( ( -M12_realM21_imag + M12_imagM21_real) / (M12_realM21_real + M12_imagM21_imag) )

I will send the FR Angle Correction algorithm as soon as possible.

PS: It is supposed the Quad-Pol scattering matrix was already calibrated for channels x-talk and imbalance. The SNAP polarimetric calibration performs it, doensn’t?

3 Likes

Following is the correction for the Scattering Matrix (S) using the “FR_angle” band estimated before:

Shh_new
real: `cos(FR_angle) * (cos(FR_angle)*i_HH-sin(FR_angle)*i_VH) + sin(FR_angle) * (cos(FR_angle)*i_HV-sin(FR_angle)*i_VV)`
imag: `cos(FR_angle) * (cos(FR_angle)*q_HH-sin(FR_angle)*q_VH) + sin(FR_angle) * (cos(FR_angle)*q_HV-sin(FR_angle)*q_VV)`

Shv_new
real: `-sin(FR_angle) * (cos(FR_angle)*i_HH - sin(FR_angle)*i_VH) + cos(FR_angle) * (cos(FR_angle)*i_HV-sin(FR_angle)*i_VV)`
imag: `-sin(FR_angle) * (cos(FR_angle)*q_HH - sin(FR_angle)*q_VH) + cos(FR_angle) * (cos(FR_angle)*q_HV-sin(FR_angle)*q_VV)`

Svh_new
real: `cos(FR_angle) * (sin(FR_angle)*i_HH + cos(FR_angle)*i_VH) + sin(FR_angle) * (sin(FR_angle)*i_HV+cos(FR_angle)* i_VV)`
imag: `cos(FR_angle) * (sin(FR_angle)*q_HH + cos(FR_angle)*q_VH) + sin(FR_angle) * (sin(FR_angle)*q_HV+cos(FR_angle)* q_VV)`

Svv_new
real: `-sin(FR_angle) * (sin(FR_angle)*i_HH + cos(FR_angle)*i_VH) + cos(FR_angle) * (sin(FR_angle)*i_HV + cos(FR_angle)* i_VV)`
imag: `-sin(FR_angle) * (sin(FR_angle)*q_HH + cos(FR_angle)*q_VH) + cos(FR_angle) * (sin(FR_angle)*q_HV + cos(FR_angle)* q_VV)`

1 Like

Visual comparison of HV_intensity over ocean area:

• you may see subtle ocean waves patterns on the corrected image that are not visible at the original one.

original:

FR corrected:

thank you for sharing it. I would love to have it implemented in SNAP beacuse I often wasn’t secure about the quality of polarimetric calibration.
Would you apply it before or after the Orientation Angle correction? Or instead?

ABraun,

The Faraday Rotation correction must be applied before the evaluation of Orientation Angle tilt.

Going further, for some applications you don’t need the correction of Orientation Angle, but the tilt itself.
For example see: 01293798.pdf (1.5 MB)

Cheers!

1 Like

thanks for the hint - I’ll have a look at this paper - looks interesting at first sight!

Thanks Gustavo, we’ll look to implement this.

2 Likes

Great, @lveci!

Now, I am facing some problems with SNAP:

• All the corrected bands were saved and renamed following the standard names (i_HH, q_HH etc…), after deleting the original ones.
• When I try to create the T3 matrix, an error message says that “it is not a full pol product” and the pixel values in all the corrected bands became ZERO.

Maybe with Snappy it would work?

It should just be looking if all polarizations are available in the band names. getSourceProductType determines what type of polarimetric product it is. For T3 it needs full pol.

https://github.com/senbox-org/s1tbx/blob/master/s1tbx-io/src/main/java/org/esa/s1tbx/io/PolBandUtils.java

1 Like

I had a look at the paper suggested by @gusortiz and found it very interesting.

I stumbled upon the publication

Schuler, D. L., Lee, J. S., & De Grandi, G. (1996). Measurement of topography using polarimetric SAR images. IEEE Transactions on Geoscience and Remote Sensing, 34(5), 1266-1277.
http://ieeexplore.ieee.org/abstract/document/536542/

and

Schuler, D. L., Lee, J. S., Ainsworth, T. L., & Grunes, M. R. (2000). Terrain topography measurement using multipass polarimetric synthetic aperture radar data. Radio Science, 35(3), 813-832.
http://ieeexplore.ieee.org/abstract/document/7770718/

Ì never heard of the application of QuadPol data for Terrain characterizations. The authors provide a way to extract slopes from full polarized data which are somehow present in the QuadPol scattering matrix. Integrating these slopes by solving a poisson equation then enables to derive elevations.

Has anyone of you heard of this approach yet? I wonderd why it didn’t become famous such as InSAR DEM generation.
What is the language of the code (patent, see below, page 28 onwards)? I’d love to try it (as now ALOS QuadPol data of 6m spatial resolution is available) but I am currently not sure if it’s worth the effort.

You can find a detailed description here:

@ABraun, I am assessing such approach to evaluate ocean surface slopes. See:

Schuler, D. L. et al. Measurement of ocean surface slopes and wave spectra using polarimetric SAR image data. Remote Sensing of Environment, v. 91, n. 2, p. 198–211, 2004.
http://www.sciencedirect.com/science/article/pii/S003442570400078

You may note the authors used AIRSAR data and still unclear (for me) the capability of ALOS/PALSAR for such method. (More recent techniques were validated for C-band (Radarsat-2))

So far, for ALOS/PALSAR, I had good results for estimating the range slope (with alpha angle approach).
However, the azimuth slope evaluation uses the tilt of orientation angle as basis and its results for ALOS/PALSAR are not good. That’s why I am getting deeply into the polarimetric calibration.

It should be great if you also get interested in that methods. Go ahead and let’s share the goals!

@gusortiz: Thank you for the response. The paper you suggest is also intersting. What I wonder is that they mostly speak of “circular polarization” which is not be the exact same as quad-polarized data, right.

I already derived the orientation angle out of ALOS-2 data but as you say, it is not sufficient as azimuth information is kind of missing.
I’ll have to have a look at it again but i still think it’s an interesting topic. But I’m afraid it won’t be of greater quality than InSAR approaches for DEM generation…