0
$\begingroup$

Rosanswers logo

Hi all,

I have a camera that is giving me JPEG images.

The compressed_image_transport overview says: "When writing a driver for such a camera, a quick and dirty approach is to simply copy the JPEG data into a sensor_msgs/CompressedImage message and publish it on a topic of the form image_raw/compressed."

So:

1- I guess there isn't any way to use image transport and saying the data we are publishing is compressed. Right?

2- If the alternative way is "quick and dirty" what would be the proper way to do this?

Thanks in advance,


Originally posted by Jep on ROS Answers with karma: 195 on 2013-07-01

Post score: 1

$\endgroup$

2 Answers 2

1
$\begingroup$

Rosanswers logo

you can republish the compressed image as an uncompressed image:

rosrun image_transport republish compressed in:=/image_raw out:=/image_raw


Originally posted by tb12 with karma: 21 on 2017-02-27

This answer was NOT ACCEPTED on the original site

Post score: 1

$\endgroup$
1
$\begingroup$

Rosanswers logo

  1. By publishing the message as message type CompressedImage, you are implicitly saying that the image is compressed. You should further indicate that by using standard naming conventions for the topic. The compressed image topic ends with "/compressed". So you might use a topic like "/image/compressed" or just "image/compressed", if you have only one camera. (You'll notice that in some tools, and in the image_transport package, you will specify the topic name without that suffix, and instead specify that the transport is "compressed". Rviz is one such tool.)
  2. In this case the "quick and dirty" approach is a very valid ROS mechanism. MJPEG compressed video format is just a sequence of JPEG images. Those are easy to deal with in OpenCV and do a reasonable job of compression, albeit not as small as more sophisticated schemes. And they have the advantage that individual frames can be processed separately, because there is no "key frame"/"intermediate frame" distinction. Unless you have performance or bandwith problems, using JPEG image frames is "proper" enough. On the other hand, if you want to publish uncompressed frames, because downstream nodes can't handle compressed images, then you can decompress as soon as you receive the frames using OpenCV and publish uncompressed. (In my case I'm getting JPEG frames in an MJPEG stream from a Raspberry Pi camera and publishing them compressed, because further processing is happening on another host, so the frames are sent across the network. If I were processing them on a single host it might be more efficient to publish them uncompressed, but you might have to measure to make sure.)

Originally posted by Mark Rose with karma: 1563 on 2018-06-28

This answer was NOT ACCEPTED on the original site

Post score: 1

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.