Creating Radar Vegetation Index

siva_iirs is referring to tomcater’s post at #7 in this topic: Creating Radar Vegetation Index

You can click this icon to see if a post is a direct answer to a previous post and display it:
grafik

1 Like

For dual-pol Sentinel-1 like data, RVI can be formed by 4*VH/(VV+VH). Here, VV and VH are in linear power scale, not in dB.
Be careful with the processing step (old SNAP7.0 version produces opposite channel c11==VV and c22==VH). However, latest version is working fine.
Read: Covariance Matrix C2 for Sentinel-1 --Diagonal Elements

1 Like

Do you mean linear power scale can be obtained from covariance matrix C2 for Sentinel-1?

Yes, they can be obtained from C2 matrix. However, in a direct approach, radiometric calibration also provides Sigma0_VV and VH.

I disagree. You can derive T or C matrix out of the initial scattering matrix S, but not vice versa.

@ABraun Hi,ABraun.
Could you explain what the white area with high value( > 1) means in rvi image?
Rvi band


VH band

VV band

And I tryed servel sentinel-1 GRD scenes for rvi. Whatever there is white strip white area like above,there are always many pixeles with value greater than 1.


Does it make sense ?

Thanks for your time!

It looks like Radio Frequency Interference (RFI). There is a transmitter on the ground that is generating C-band RF emissions that are disturbing S-1 image formation.

3 Likes

Thanks for your reply. Do you have any idea about the pixels with value greater than 1 exept RFI?
At the moment,I don’t know how to handle those pixels.

The RFDI was developed based on all four polarizations. If you adjust the equation because you are using Sentinel-1 with only VV and VH, it is not surprising that the value range is a bit different. Unlike the NDVI it is not strictly limited to -1 and +1 but rather a relative measure of the presence of vegetation. Also, it fails at artificial structures, such as urban bodies.
Use the mask manager to identify RFDI pixels > 1 and check where in the image they are.

1 Like

Sir,it seems that there is still no obvious threshhold between RFDI pixels and other normal pixels with value > 1.
mask by > 1


mask by > 1.3

And I read some discussion and know there are no way to remove RFDI currently.
So this makes things harder,have to make a median composite and interpolate by previous and post scenes.

you could mask out these areas entirely to exclude them from the median composite.

Hi,

It also happens to me, RVI > 1. Can it be fixed?

thanks!


Hi,

I tried to use RVI using GEE platform, but find a problem to de convert the unit from dB to linier scale, does anyone know the right script to do it?

thank you

In the link bellow the RVI is calculated a bit differently (using S1 GRD products).
Do you think you can possibly explain the difference between the two formulas ?
What are they represent and what are their differences?

RVI

image

@ABraun Please help, can anyone tell me why my value range on RVI is from 0-255 and not from 0-1? How do I get the range to be similar to NDVI? I’ve noticed that (everyone) else managed to get the range from 0-1 (approximately).
I have followed all of the pre-processing steps explained in this thread.
I used the 4VH/(VV+VH) formula in band math
Thanks!

Here’s a version translated using Yandex. The formatting isn’t great, but it’s understandable. I wonder if this formula can be applied to ALOS HH/HV data instead of VV/VH. I’ll give it a try.
16-24(1).pdf (337.2 KB)

It seems to have lost the images in the version I attached, but if anyone is interested in this paper you can translate/read it by adding the Russian version here: Online translation of documents into Russian and other languages – Yandex.Translate

We’ve published some interesting facts about RVI behavior. A little bit of playing with Relative orbits provided smoother RVI results. It seems that there is a quite broad space for filtering (e.g. savitzky-golay filter)

Link: https://link.springer.com/article/10.1007%2Fs11119-021-09844-5

4 Likes

I might be a little late to the party here. But this comment just touched on something that could have huge ramification for a project I work on. I hope you are still around here and have the time to clarify! @ABraun

I am working on a pipeline that was created before I joined the project. I have recently realised that all S1 data is processed via SNAP and then scaled (linear_to_dB). Now I understand that conventionally the scaling to dB is mostly done for us to be able to visualise the VV, VH, LIA outputs. Perhaps also for statistical stability (outliers etc). But in this project the S1 images are never visualised. They are used purely for statistics generation of mean pixel values within given field boundaries. Values extracted are mean VV, mean VH, mean LIA and mean RVI.
Essentially your comment tells me that the RVI data is calculated in a wrong manner, because it is computed based on logartihmic scaled VV and VH data.
Is that correct?

Furthermore I found this comment: “In a logarithmic scale, the division operation is not equivalent to the division in linear scale. Therefore, if you have data in dB, you should not directly apply the RVI formula that involves division. The correct procedure when working with data in dB is to first convert it back to linear scale before applying the RVI formula. The conversion from dB to linear scale is done using the inverse of the logarithmic function”

So by that logic I could use
linear=10 ** (0.1*dB_data)

def db_to_linear(data):
    return 10 ** (0.1 * dB_data)

to convert the pixel values back to linear and then feed that into the RVI formular as you described it: RVI = 4VH/VV+VH, right?

Furthermore, the other statistics that are calculated are still based on dB data. At this point I wonder if it makes sense at all to transform the data from linear to logarithmic scale?
As more providers are producing and putting S1 RTC up for grab, I notice that they do not use the dB scale at all in the data. Like Microsoft Planetary S1 RTC or Alaska Satellite Facility S1 RTC. If this is the case I believe we can save some processing time by omitting the whole dB thing.

I would love your or anyone elses opionion on this.
Thank you for your time!

If RVI is being calculated after scaling to dB, then yes, you’re likely not getting the linear values that RVI computation requires. The conversion method you mentioned, linear=10 ** (0.1*dB_data), is correct to revert dB to linear before applying the RVI formula.

Also, regarding the use of dB scale, it’s generally for visualization and handling outliers, as you mentioned. If your project’s focus is purely statistical analysis within specific field boundaries and not on visual interpretation, then skipping the dB conversion could indeed save processing time, especially if the end-users of your data are comfortable with linear scale values, which seems to be an emerging trend with S1 RTC providers.

I’d say, review the end goals of your data processing, and if visualization isn’t necessary, and your statistics work in linear scale, it seems logical to streamline your process.

1 Like