2 ms·
This is actually a pretty good argument for sparse data handling; push some intelligence out to the edges of your network (e.g. the spy satellites or what have
by staticfloat 8y ago
This is actually a pretty good argument for sparse data handling; push some intelligence out to the edges of your network (e.g. the spy satellites or what have you) that are collecting the data in the first place, and then only store "interesting" pixels. E.g. regions where there are movement; regions already determined to be of interest (densely populated areas, war zones, trading vessel corridors, etc....)
There is research going on right now to build native camera systems that emit data (at the hardware level) that is not dense but rather sparse; information is transmitted as "blocks of pixels that changed between frame two and three" rather than "here is the state of all pixels at frame two, and here is the state of all pixels at frame three". In essence, doing a small amount of delta compression within the hardware itself.
This seems like a really natural fit for an application such as this one; and could potentially cut the amount of data needed to be paid attention to down by orders of magnitude.
Many of these ideas are similar to what is used to compress video down in the first place; it would be interesting to see a combination of video compression technology and "region of interest" ML pruning, where the ML models are applied only to interesting regions, as identified by the compression codec. The codec already has done the analysis to figure out which portions of the video have changed, which portions of the video are simply shifted versions of information from the last frame, etc.... You could significantly speed up ML analysis by making use of that kind of information.
- trevyn 8y ago>In essence, doing a small amount of delta compression within the hardware itself. This is already what hardware video codecs do well. If you’re talking about Chronocam-style differential sensors, they have their specialized use cases, but this is not one of them. Bandwidth from your sensor to your codec is already obscenely high, and you’re on a moving platform anyway. As far as what video to actually store or do further processing on, ML ROI absolutely makes sense. This is basically what the Google Edge TPU is for: https://cloud.google.com/edge-tpu/ https://cloud.google.com/edge-tpu/
- photojosh 8y agoIf anyone's interested to read more, I know of them as "event cameras" (as distinguished from "pixel cameras". [0] is one of the universities doing research into them. We're intrigued to use them one day for our automation solutions, but they're a bit pricey at this stage. A huge advantage of them is that you have practically instant latency on the output, as opposed to restricted frame rates with motion blur from traditional cameras. Have a look at [1] for a few demos. The spinning bucket path reconstruction and drone visual odometry are my favourites. [0] http://rpg.ifi.uzh.ch/research_dvs.html http://rpg.ifi.uzh.ch/research_dvs.html [1] https://www.youtube.com/watch?v=F3OFzsaPtvI https://www.youtube.com/watch?v=F3OFzsaPtvI