Hi Dan,

On Mon, Jun 21, 2010 at 10:29 AM, Dan Lazewatsky
<lazewatskyd@cse.wustl.edu>wrote:

> I was wondering what the status of the python bindings for
> image_transport is.
>

There hasn't been any serious work on Python bindings for image_transport.

They would definitely be nice to have, but actually writing them presents
some thorny technical issues. Either you need to write pure-Python analogues
of image_transport *and* all plugins, or find a way to wrap the C++
implementation and reuse the existing plugins. The latter approach seems
more attractive in terms of code reuse and not increasing the burden on
plugin implementers; but it requires changing the plugin interfaces to
abstract away explicit use of roscpp (NodeHandle), as that won't play nice
with rospy in the same process.

In short: this is all possible, just unpleasant and time-consuming. Since
dropping in an extra republish node works adequately, I haven't made it a
priority.

I've been limping along either using C++ or subscribing directly to
> image messages in python, but it's starting to become a problem. The
> republish idea on the wiki doesn't seem like a particularly good
> solution.


Sometimes it is actually the best solution! If the image topic is published
on machine A and there are multiple subscribers on a machine B, republishing
the images in raw format on machine B minimizes both network bandwidth and
CPU usage.

For the one-to-one case - only one subscriber on the second machine - it's
true that spinning up a republish node is an inconvenience and adds a little
latency. I'd suggest adding it to your subscriber-side launch file.

Cheers,
Patrick