On 30/05/12 06:45, Cedric Pradalier wrote:
> On Wed, May 30, 2012 at 3:18 AM, Edwards, Shaun M.<sedwards@swri.org> wrote:
>> +1 if the compress/decompress helps with point clouds and images.
>>
>
> I'm quite confident it will help with point clouds and images. Also
> occupancy grids should compress very well.
>
> For images though, it might not work as well as the image_transport
> plugin. The latter can take advantage of more knowledge and use lossy
> compression (Jpeg or Theora) to reduce the bandwidth more drastically.
> For lossless compression, it should be roughly equivalent: PNG and BZ2
> use very algorithm AFAIK.
>
> This is actually a good point in favour of having the two mechanisms:
> a generic preprocessing of the messages at the level of the
> publisher/subscriber and a message transport architecture that can be
> instantiated for specialized preprocessing on well defined types.
For real-time compression of large data, snappy is probably a very good
solution [1]:
"Snappy is a compression/decompression library. It does not aim for
maximum compression, or compatibility with any other compression
library; instead, it aims for very high speeds and reasonable
compression. For instance, compared to the fastest mode of zlib, Snappy
is an order of magnitude faster for most inputs, but the resulting
compressed files are anywhere from 20% to 100% bigger. On a single core
of a Core i7 processor in 64-bit mode, Snappy compresses at about 250
MB/sec or more and decompresses at about 500 MB/sec or more.
Snappy is widely used inside Google, in everything from BigTable and
MapReduce to our internal RPC systems. (Snappy has previously been
referred to as “Zippy” in some presentations and the likes.) "
Kind regards,
Stéphane
[1]
http://code.google.com/p/snappy/
--
Dr Stéphane Magnenat
http://stephane.magnenat.net
(text/plain)