On Fri, Apr 16, 2010 at 4:03 PM, Patrick Mihelich
<mihelich@willowgarage.com> wrote:
> On Fri, Apr 16, 2010 at 8:26 AM, Jack O'Quin <jack.oquin@gmail.com> wrote:
>>
>> 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.

OK, thanks. That helps quite a lot.

I did not understand that I could use TransportHints or
~image_transport in my node, as well. I missed that idea while reading
the docs.

> 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.

Now I understand that the decompression happens in the subscriber(s),
that makes sense.

>> 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.
>
> We're all still figuring that out. Recording the compressed topics is a good
> method. We're working on adding compression to bag files, but
> domain-specific compression like JPEG or PNG will always beat
> general-purpose algorithms.
>
> If you don't mind "thinning out" your data, you can also use topic_tools to
> limit your data topics to a maximum bandwidth or rate. Although, it occurs
> to me that these don't have good support for synchronized topics like
> image_raw/camera_info yet.

I very much appreciate the informative reply, Patrick.

Sounds like what we are doing is pretty good, with only a few minor
tweaks required for automatic decompression. That's encouraging.

Regards,
-- 
 joq