The number of looks correlates with a higher resolution.
Yes and no. When you task an image, you usually (as is the case with Umbra) specify your desired ground resolution, eg. 25, 50, 100 cm, etc. There are two dimensions in a SAR image: range and azimuth. Range resolution is determined by the SAR system bandwidth. Azimuth resolution is determined by the integration angle (the angle formed between your target and your satellite from start to end of the collection).
Let's assume you want a 50 cm image. Your range resolution will be equal to that and, in a 1-look image, your native azimuth resolution will also be 50 cm. What happens when you request a multi-looked image, is that the satellite will collect data over your target for a longer amount of time (and thus over a greater angle diversity). Range resolution will not change; however, in the natural ("native") image, you get asymmetrical pixels: taking the same target resolution of 50 cm, a 2-looks image will have a 25 cm azimuth resolution. For 3-looks, ~16 cm. And so on.
What then happens during the processing of derived products (eg. GEC) is that the pixels are squared: to do that, you have to average out the pixels in the azimuth dimension. This greatly improves what is called the radiometric resolution (ie. how much information a pixel contains), by cancelling out the speckle and averaging the noise. But for all intents and purposes, on a multi-looked image (which is what the GEC products that you use are), spatial resolution remains the same, square pixel.
[SAR nerds here: I am not mentioning the slant-range-to-ground-range process, and I am also ignoring the resolution vs. sampling distinction for simplicity]
Quick geospatial note that's important for accurately geolocating these images:
You need a DEM to use RPCs for geolocation. Running things through gdalwarp as was done here will assume no terrain and 0 elevation. That will lead to significant mislocations anytime it's not flat and at sea level, especially given the off-nadir view angle of the data used here.
If you don't want to use a DEM for orthographic corrections, then you should at least include a constant elevation in meters of the scene with RPC_HEIGHT. Otherwise things can be shifted kilometers from where the image actually is.
A company called Erim back in the 70's pioneered SAR systems. They had an interesting approach to processing and storage of the data which was all analog back then. They used holography. Erim and their SAR work is documented in wikipedia but their company presidents obsession with holography was detailed in their monthly news letters. I was handed some of these documents from a former (now deceased) worker at Erim. He told me how they were able to fly the massive radar systems and the huge analog computers they used to process the data. It must have been absolutely wild to work there in those days.
Man there’s everything to love about this. A novel free dataset, complete example code, clear description of how to get it up and running—the ideal blog post IMHO. Delighted to learn about it.
m2fkxy ·126 days ago
Let's assume you want a 50 cm image. Your range resolution will be equal to that and, in a 1-look image, your native azimuth resolution will also be 50 cm. What happens when you request a multi-looked image, is that the satellite will collect data over your target for a longer amount of time (and thus over a greater angle diversity). Range resolution will not change; however, in the natural ("native") image, you get asymmetrical pixels: taking the same target resolution of 50 cm, a 2-looks image will have a 25 cm azimuth resolution. For 3-looks, ~16 cm. And so on.
What then happens during the processing of derived products (eg. GEC) is that the pixels are squared: to do that, you have to average out the pixels in the azimuth dimension. This greatly improves what is called the radiometric resolution (ie. how much information a pixel contains), by cancelling out the speckle and averaging the noise. But for all intents and purposes, on a multi-looked image (which is what the GEC products that you use are), spatial resolution remains the same, square pixel.
[SAR nerds here: I am not mentioning the slant-range-to-ground-range process, and I am also ignoring the resolution vs. sampling distinction for simplicity]
Show replies
jofer ·126 days ago
You need a DEM to use RPCs for geolocation. Running things through gdalwarp as was done here will assume no terrain and 0 elevation. That will lead to significant mislocations anytime it's not flat and at sea level, especially given the off-nadir view angle of the data used here.
In other words:
Should be: If you don't want to use a DEM for orthographic corrections, then you should at least include a constant elevation in meters of the scene with RPC_HEIGHT. Otherwise things can be shifted kilometers from where the image actually is.Show replies
skinwill ·126 days ago
tomcam ·126 days ago
1f60c ·126 days ago
I think they're referring to this: https://umbra.space/open-data/ (warning: most files are absolutely ginormous)
Show replies