[ros-users] roscpp with transport plugins

Stéphane Magnenat stephane.magnenat at mavt.ethz.ch
Wed May 30 05:59:17 UTC 2012

On 30/05/12 06:45, Cedric Pradalier wrote:
> On Wed, May 30, 2012 at 3:18 AM, Edwards, Shaun M.<sedwards at 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,


[1] http://code.google.com/p/snappy/

Dr Stéphane Magnenat

More information about the ros-users mailing list