ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Why do most ROS image nodes lack support for CompressedImage?

asked 2016-03-18 13:02:41 -0500

Cerin gravatar image

I'm trying to setup a simple mjpeg stream from a webcam, and I'm finding most of the common image processing packages provide no support for CompressedImage. Why is this?

For example, neither the deprecated mjpeg_server nor recommended web_video_server nodes supported compression as input, causing them to consume massive amounts of CPU. Even basic transformation nodes like image_rotate only supports the uncompressed Image type.

I'm finding I have to write a lot of ROS nodes from scratch...just to process Jpegs. Am I missing something? Why does the ROS community eschew efficient compression? I get there's some minor loss in quality with compression, but I'm seeing a 10-fold difference in CPU consumption between the compressed and uncompressed image streams. On mobile platforms with limited resources, that's a huge problem.

edit retag flag offensive close merge delete


Do those packages use the image_transport library? If they do, they should support compression through compressed_image_transport

ahendrix gravatar image ahendrix  ( 2016-03-18 18:18:01 -0500 )edit

Have you tried requesting compressed transport by setting the ~image_transport parameter to compressed for each node in question?

ahendrix gravatar image ahendrix  ( 2016-03-18 18:25:15 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2016-03-19 09:52:32 -0500

Wolf gravatar image

For mjpeg_server and web_video_server you are right, here using a compressed input can help reducing CPU usage as the nodes would no longer have to compress the stream internally before streaming to the browser.

However, in general this is not the case for nodes doing image processing. For example the transformation node internally needs the raw image data in order for performing the image transformation (E. g. see ). I e. if you would require it to use compressed streams and input and output it would have to decompress at the input and compress again at the output --> likely much higher CPU usage for a slightly reduced data traffic. And it comes worth: Think of an image processing pipeline --> each processing step element would have to decompress at beginning and compress when the image leaves. Dramatic CPU usage and moveover the image quality does not decrease ones but step by step decreases while passing through the chain.

Hence, most of the times it is better to use the uncompressed stream for processing chains and only compress the image ones, directly before passing it through the network.

edit flag offensive delete link more


I was thinking about CPU optimization and came to the same conlusion as you. However, i don't understand why a simple usage of image_rotate is so ineficient in terms of CPU.

doisyg gravatar image doisyg  ( 2017-08-31 07:31:17 -0500 )edit

Question Tools



Asked: 2016-03-18 13:02:41 -0500

Seen: 379 times

Last updated: Mar 19 '16