Sir,it seems that there is still no obvious threshhold between RFDI pixels and other normal pixels with value > 1.
mask by > 1
you could mask out these areas entirely to exclude them from the median composite.
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?
@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
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.
Thank you for your answer! I really appreciate this clarification.