# Sending images over socket/pyigtl takes very long in 3D Slicer

**URL:** <https://discourse.slicer.org/t/sending-images-over-socket-pyigtl-takes-very-long-in-3d-slicer/42569>\
**Category:** Support\
**Created:** [April 15, 2025, 7:48am UTC](https://discourse.slicer.org/t/sending-images-over-socket-pyigtl-takes-very-long-in-3d-slicer/42569 "2025-04-15T07:48:28Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Daniel\_L](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/daniel_l/32/18424_2.png) [@Daniel\_L](https://discourse.slicer.org/u/Daniel_L)\
**Post date:** [April 15, 2025, 7:48am UTC](https://discourse.slicer.org/t/sending-images-over-socket-pyigtl-takes-very-long-in-3d-slicer/42569/1 "2025-04-15T07:48:28Z")

</div>

Hello everyone!

I am using a Raspberry Pi with an Intel Realsense to send images to 3D Slicer over a socket connection to create a point cloud out of them. Now sometimes it takes a very long time until the image is received in Slicer, it is irregular in between 2 seconds and 20 seconds.  
The thing is that on the Pi’s case I mounted a tracking tool, that is additionally tracked by a NDI camera, because I want to have the real life position of the point cloud that is created afterwards. Now the problem is if I move the tracked camera in between transmission, the position of the camera is different than to the time I took the image. That is why I send beforehand just a single Triggerbyte to capture the transformation. But even just receiving the trigger byte takes sometimes up to 10 seconds.

I also tested the same receiving code outside of Slicer, just with a VSC code and the triggerbyte is received instantly.  
Also I tried using “my own” socket connection, as well as a pyigtl implementation, there was no difference in transmission speed.  
Another interesting thing I noticed was that I feel like if I click into the 3D Slicer scene the byte comes as I click. It feels like Slicer only updates when clicked into the scene (and also after an irregular amount of time)

Did anyone have a similar issue?  
I am glad for every help received.

---

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [April 17, 2025, 4:38am UTC](https://discourse.slicer.org/t/sending-images-over-socket-pyigtl-takes-very-long-in-3d-slicer/42569/2 "2025-04-17T04:38:41Z")

</div>

You can directly connect your computer to a RealSense camera and an NDI tracker and stream synchronized tracking and point cloud data via OpenIGTLink using Plus toolkit. You csn receive updates within a fraction of a second. The Slicer module that can receive the data is available here:

> **[GitHub - PerkLab/DepthImageToPointCloud: This repo contains a slicer module for generating...](https://github.com/PerkLab/DepthImageToPointCloud)**
>
> This repo contains a slicer module for generating point clouds from static or streamed depth images.

---

<div class="post-metadata">

**Author:** ![Daniel\_L](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/daniel_l/32/18424_2.png) [@Daniel\_L](https://discourse.slicer.org/u/Daniel_L)\
**Post date:** [April 18, 2025, 8:58am UTC](https://discourse.slicer.org/t/sending-images-over-socket-pyigtl-takes-very-long-in-3d-slicer/42569/3 "2025-04-18T08:58:21Z")

</div>

Hello Andras,

Thank you for your reply. I already know about this slicer module and in fact I have been adapting it to my use case for over a year now 🙂 . So my first steps were obviously to connect it to the computer and test everything from there. With that setup everything worked smoothly and as you said withing a fraction of a second I get the data. But now I would like the setup to be wireless, so I build a device including a Raspberry Pi, which sends the depth image of the Realsense over a socket connection to Slicer every button press. And here comes the issue I described.

So I want it to be transmitted over Wifi, so it is cableless. Do you have any experience with such described delays?