Hey, I wrote GeoDeep, what a cool writeup! Glad someone tried to run these on satellite imagery. I did most of my testing on drone derived orthophotos, so was curious to see how it would perform with lower resolution images. Some models like the car model seem like they did poorly. I suspect it's probably because the ground sampling distance (GSD) was in the 35-56 cm/px range, whereas the car model was trained for 10 cm/px. GeoDeep can downscale the input to match the model's input resolution, but can't (currently) upscale it.
Very cool project! It works about as well as I would expect if you naively take a drone derived model and apply it to satellite images, but I am sure a bit of fine-tuning would improve performance.
Good job on the ease of use front: it does look really easy to use.
Thankfully this is also right in the window of much of what's being captured from aircraft in many places, too. It's not uncommon to find 7.5 - 15cm / px imagery from public agencies around the globe. Even some more philanthropic acquisitions are acquiring within this envelope.
Id love to read a little more about why onnx was chosen specifically, and what it brings to the game.
There is currently a gap in open and decent models which can be applied to high resolution orthographic imagery, specifically with regards to collection of additional community resilience artefacts such as solar panels and pools. Theres plenty of vendors who want to sell such data, but its so far out of reach of so many worldwide that an open source set of models would go a hell of a long way.
On the ONNX choice: it's fairly lightweight to install and runs decently fast on a CPU. Other existing libraries forced me to install torch or tensorflow.
Does the library inherently handle threading and concurrency to make use of beefier CPUs, or does that need to be coded in to the users Python script? I'm asking as I'll most likely have a go at extending a current project with a custom model or two and am tossing up where to put money in PC hardware. I suspect I'll need to invest both in GPU and CPU, the former for training, and the latter because not everything runs on GPU.
The inference process via ONNX (where most of the CPU time is spent) is multi-threaded. I briefly explored adding multiprocess capabilities for the tiling/downsampling/result merging parts of the codebase, but the improvements were marginal with a trivial implementation, so I didn't explore further (although I'm sure it could be improved).
Cool post. I'd be interested in seeing models likes this deployed to the satellites themselves.
Typically, data gathered from satellites needs to wait for the satellite to do a pass over a dedicated ground station before it can be processed, which is probably somewhere in the US. If you move the processing from the ground station to the satellite, then you 1. Don't have to transmit as much data, 2. Can transmit actionable intelligence much faster. It can be upwards of 90 minutes before a satellite passes over it's ground station. If you could get that down to a few seconds, I could see some serious applications in disaster response.
> It can be upwards of 90 minutes before a satellite passes over it's ground station.
Planet Pelican will have the ability to communicate with other satellites, meaning you don't necessarily need a ground station: https://www.planet.com/products/pelican/
> 1. Don't have to transmit as much data
There is definitely a bit of a move to do some work on the actual satellite, depending on the use case. This is pretty doable if you have a very specific use case for which you can optimize this, but gets a little bit harder if you have to have it work for every possible use case.
From discussions I've seen online, a lot can fail on satellites so there is a bias to do as little as possible on them. There does appear to be plenty of bandwidth to transmit back to ground stations.
The real win will be satellite-to-satellite transmissions where any data collected by the constellation is passed to the satellite that'll next fly over a ground station. This will lower the time from capture to analysis considerably. The fresher the data, the more valuable it is.
It’s possible I’m missing visibility into some part of the industry, but I don’t think this has been true for quite some time. There are multiple providers of Ground Segment as a Service that satellite operators can buy radio time from across the globe that are in the billions of yearly revenue. Most satellites are transmitting to the nearest ground stations in one or more networks live and transported over IP unless that capability isn’t required.
Hey, I wrote GeoDeep, what a cool writeup! Glad someone tried to run these on satellite imagery. I did most of my testing on drone derived orthophotos, so was curious to see how it would perform with lower resolution images. Some models like the car model seem like they did poorly. I suspect it's probably because the ground sampling distance (GSD) was in the 35-56 cm/px range, whereas the car model was trained for 10 cm/px. GeoDeep can downscale the input to match the model's input resolution, but can't (currently) upscale it.
Very cool project! It works about as well as I would expect if you naively take a drone derived model and apply it to satellite images, but I am sure a bit of fine-tuning would improve performance.
Good job on the ease of use front: it does look really easy to use.
Thankfully this is also right in the window of much of what's being captured from aircraft in many places, too. It's not uncommon to find 7.5 - 15cm / px imagery from public agencies around the globe. Even some more philanthropic acquisitions are acquiring within this envelope.
Hey, love this write up, thank you.
Id love to read a little more about why onnx was chosen specifically, and what it brings to the game.
There is currently a gap in open and decent models which can be applied to high resolution orthographic imagery, specifically with regards to collection of additional community resilience artefacts such as solar panels and pools. Theres plenty of vendors who want to sell such data, but its so far out of reach of so many worldwide that an open source set of models would go a hell of a long way.
Thanks also for including your PC specs.
On the ONNX choice: it's fairly lightweight to install and runs decently fast on a CPU. Other existing libraries forced me to install torch or tensorflow.
Awesome, thank you.
Does the library inherently handle threading and concurrency to make use of beefier CPUs, or does that need to be coded in to the users Python script? I'm asking as I'll most likely have a go at extending a current project with a custom model or two and am tossing up where to put money in PC hardware. I suspect I'll need to invest both in GPU and CPU, the former for training, and the latter because not everything runs on GPU.
The inference process via ONNX (where most of the CPU time is spent) is multi-threaded. I briefly explored adding multiprocess capabilities for the tiling/downsampling/result merging parts of the codebase, but the improvements were marginal with a trivial implementation, so I didn't explore further (although I'm sure it could be improved).
Great, thank you!
Cool post. I'd be interested in seeing models likes this deployed to the satellites themselves.
Typically, data gathered from satellites needs to wait for the satellite to do a pass over a dedicated ground station before it can be processed, which is probably somewhere in the US. If you move the processing from the ground station to the satellite, then you 1. Don't have to transmit as much data, 2. Can transmit actionable intelligence much faster. It can be upwards of 90 minutes before a satellite passes over it's ground station. If you could get that down to a few seconds, I could see some serious applications in disaster response.
> It can be upwards of 90 minutes before a satellite passes over it's ground station.
Planet Pelican will have the ability to communicate with other satellites, meaning you don't necessarily need a ground station: https://www.planet.com/products/pelican/
> 1. Don't have to transmit as much data
There is definitely a bit of a move to do some work on the actual satellite, depending on the use case. This is pretty doable if you have a very specific use case for which you can optimize this, but gets a little bit harder if you have to have it work for every possible use case.
From discussions I've seen online, a lot can fail on satellites so there is a bias to do as little as possible on them. There does appear to be plenty of bandwidth to transmit back to ground stations.
The real win will be satellite-to-satellite transmissions where any data collected by the constellation is passed to the satellite that'll next fly over a ground station. This will lower the time from capture to analysis considerably. The fresher the data, the more valuable it is.
I’m literally working on this at Planet right now :)
https://www.businesswire.com/news/home/20240610385569/en/Pla...
It’s possible I’m missing visibility into some part of the industry, but I don’t think this has been true for quite some time. There are multiple providers of Ground Segment as a Service that satellite operators can buy radio time from across the globe that are in the billions of yearly revenue. Most satellites are transmitting to the nearest ground stations in one or more networks live and transported over IP unless that capability isn’t required.
Even AWS sells it. Pretty much a commodity.
Wouldn't that be prohibitive energy-wise? AFAIK satellites are not abundant in electrical power.
I find the blog funny for its disclaimer for the workstation specs.
> There is a heatsink on the SSD to help keep its temperature down.
Good to know!
Super interesting article and results shared by the Author, as always!
Quite surprised by the overall processing results especially on general detection of features.
[dead]