Revision history [back]

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 "<camera-name>/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.)
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.)