The problem came when writing an image_transport subscriber to process
and display the images. Just subscribing to the compressed image
published by the bag does not work.
image_view is an image_transport subscriber, so your node should be able to work with the bag just as well. Remember that you need to subscribe to '/right_front/camera/image_raw' (even though that topic does not exist in the bag) and instruct your image_transport::Subscriber to use 'compressed' transport either through the ~image_transport parameter or in code with TransportHints.
The solution you found using 'republish' is a good one if you have multiple nodes on the same machine listening to an image topic, as it avoids the CPU overhead of each subscriber node doing the decompression.
I suspect the decompression happens in the
publisher. How does image_view deal with that? (Guess I should read
the code.)
Decompression happens in the subscriber - the original motivation of image_transport was to save bandwidth. image_view simply uses an image_transport::Subscriber, which loads the appropriate plugin to decompress the images. I do suggest looking at image_view.cpp, it is a very straightforward application of image_transport. The image_transport
subscriber tutorial actually implements a slightly simplified version of image_view.
What are the recommended Best Practices for saving and using large
files like these? In minutes, these devices produce gigabytes of data,
and we plan to add four more similar cameras with a 360 degree field
of view.