<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">it's actually not that egregiously bad a solution, i've been streaming stereo images around without much problem. it was a little laggy during the pr2 workshop with all the other pr2's around but it works much better now in our lab.<div><br></div><div>besides, a python process isn't the best place to be doing low latency vision anyways...<br><div><div><br><div><div>On Jun 21, 2010, at 7:42 PM, Dan Lazewatsky wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Thanks for the update. I haven't played around with republishing too much, but I'll give it a shot again and see how it works.<div><br></div><div>-Dan<br><div><div>On Jun 21, 2010, at 6:36 PM, Patrick Mihelich wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi Dan,<br><br>On Mon, Jun 21, 2010 at 10:29 AM, Dan Lazewatsky <span dir="ltr"><<a href="mailto:lazewatskyd@cse.wustl.edu" target="_blank">lazewatskyd@cse.wustl.edu</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> I was wondering what the status of the python bindings for<br> image_transport is.<br></blockquote><div><br>There hasn't been any serious work on Python bindings for image_transport.<br><br>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.<br> <br>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.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> I've been limping along either using C++ or subscribing directly to<br> image messages in python, but it's starting to become a problem. The<br> republish idea on the wiki doesn't seem like a particularly good<br> solution.</blockquote><div><br>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.<br><br>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.<br> <br>Cheers,<br>Patrick<br></div></div> _______________________________________________<br>ros-users mailing list<br><a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br><a href="https://code.ros.org/mailman/listinfo/ros-users">https://code.ros.org/mailman/listinfo/ros-users</a><br></blockquote></div><br></div></div>_______________________________________________<br>ros-users mailing list<br><a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>https://code.ros.org/mailman/listinfo/ros-users<br></blockquote></div><br></div></div></div></body></html>