Subject:
|
Re: Rover Programming
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 27 Jun 2002 19:49:14 GMT
|
Original-From:
|
PeterBalch <PETERBALCH@COMPUSERVEsaynotospam.COM>
|
Viewed:
|
647 times
|
| |
|
|
Steve Baker wrote:
> But with a little simple on-the-fly data compression, I think you could
> solve the storage problem.
> It wouldn't take much to decompress as much of the 'map' as it currently • needs
> and place it into a small cache - recompressing that section and • uncompressing
> another into the space thus free'd up.
Run-Length-Encoding (RLE) should work well on a blobby black-and-white map.
Or you could store line N as the difference (or XOR) between line N and
line (N-1). The difference would be mostly zero. Then RLE it.
Or:
Assume one bit per map pixel. Take the detailed "image" of the map. Halve
its resolution (so its a quarter of the area). Store this small map. Now
double the stored map (to the original size) and note the difference with
the original image (e.g. XOR the two images). Store the difference image
(RLE compressed).
Now do the same but this time make lots of smaller and smaller images. Say
5 or 6 layers. You only store the smallest image and all the difference
images.
This is image compression using what's called a Laplacian Pyramid. (Look up
"Laplacian Pyramid" on the www.)
It's easy to expand just the part you need.
Peter
(I'm going to be out of touch for a while so I'm signing-off
unfortunately.)
|
|
Message has 1 Reply:
 | | Re: Rover Programming
|
| (...) Yes - and it's very fast to implement. Better still, you can use one of several rectangle encoding tricks that are out there (kind of like two-dimensional run-length encoding). Those are typically able to compress at the square of the ratio of (...) (22 years ago, 28-Jun-02, to lugnet.robotics)
|
2 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
