search

UCL / SkullBaseNavigation

Other
2 stars 1 forks source link

Increase Image transfer with the OEM interface #30

Closed tdowrick closed 3 years ago

tdowrick commented 3 years ago

In GitLab by @RemiDelaunay on Dec 13, 2018, 17:49

I have found an option in PLUS called "Continuous Streaming Enabled" (see description below) which would make the image transfer faster. The main drawback is that it requires the image size to be fixed. However, this could potentially solve #20 where we have about the streaming delay between imaging and tracking data and increase the image frame rate (we are now limited to a few frame per second).

Continuous image streaming for significantly faster image transfer, if:

@JonathanShapey : PLUS says this feature may require additional license from BK, can you check with them ?

Bk ultrasound user manual

tdowrick commented 3 years ago

In GitLab by @JonathanShapey on Dec 14, 2018, 09:02

I believe the additional license specified is the OEM license and we have already installed this on our machine.

Maybe we could try the Continuous Streaming method and if it doesn't I will then contact BK? I have already requested that they come and update the system so we can beam the formed IQ data so if required, I will ask them to do both the same day.

tdowrick commented 3 years ago

In GitLab by @DavidPerez-Suarez on Jan 14, 2019, 11:12

changed the description

tdowrick commented 3 years ago

In GitLab by @DavidPerez-Suarez on Jan 18, 2019, 16:03

assigned to @RolandGuichard

tdowrick commented 3 years ago

In GitLab by @DavidPerez-Suarez on Jan 18, 2019, 16:03

Related with #20

tdowrick commented 3 years ago

In GitLab by @AnastasisGeorgoulas on Jan 29, 2019, 13:09

@RolandGuichard and I have been experimenting with different configurations and are getting much better results. Some quick notes:

When testing with a saved image (offline testing), we get up to ~20fps according to the PLUS diagnostics tool (DiagDataCollection). In the Slicer diagnostics, we only see up to ~15fps. Setting the AcquisitionRate to higher values does not give better results, in either tool. Up to these values, though, we are getting the requested rates pretty well in both tools.

When using the real BK machine, we can get up to 20fps in the PLUS diagnostics (did not test Slicer with this IIRC). However, recompiling PLUS to hardcode a higher argument to GRAB_FRAME actually gives better results! If we GRAB_FRAME at 30, we get ~28 in the PLUS diagnostics, and ~22 in the Slicer diagnostics; if we GRAB_FRAME at 40, we get ~38 in the PLUS diagnostics, but still ~22-25 in Slicer. In all of these cases, there was very little to no effect on the frame rate by having “motion” in the US compared to the probe touching nothing.

This is all on Roland’s MacBook, with PLUS 2.7.0.

Note that when we tried the PLUS diagnostics with the BK in the Alienware laptop, we were getting ~5 fps! And trying it in offline testing mode made it (apparently) crash. This was with PLUS 2.6 which is installed in the Alienware (from memory, using both the 32 and the 64 bit version, although IIRC the 64 big gave higher values - still lower than expected though). We'll need to repeat this to make sure I wasn't doing anything wrong.

tdowrick commented 3 years ago

In GitLab by @TomVercauteren on Jan 31, 2019, 20:47

Starting with silly questions: All the dependencies were compiled in Release (or RelWithDebInfo)?

tdowrick commented 3 years ago

In GitLab by @TomVercauteren on Jan 31, 2019, 21:06

Also: Is there a specific reason to use windows? Not convinced is would be a sensible way forward given how temperamental the alienware is under ubuntu but Slicer & co is probably tested more thoroughly on linux so might be worth a shot as some point.

tdowrick commented 3 years ago

In GitLab by @RolandGuichard on Feb 1, 2019, 09:56

Hi @TomVercauteren , First answer, all dependencies were build in Release. Even the PLUS server grants you access to the diagnotics we used (DiagDataCollection) to monitor the output rate from the BK. On Slicer, there is a downloadable extension module that provides the incoming rate. Second answer (at least a personal opinion, perhaps @AnastasisGeorgoulas and @DavidPerez-Suarez have second thoughts about it), at this stage, it is hard to have a definite conclusion about which platform is preferable. We've got a reasonably solid understanding of the full build process on Mac (Plus server, Slicer + extensions) which might not be that different on a Linux machine. However, I apprehend changing OS on the Alienware at present, which is a very risky and potentially lengthy process. Moreover, I'm not sure we'll get access to all drivers, I am thinking in particular to the NVIDIA ones (but I might be wrong in this). Hope it helps.

tdowrick commented 3 years ago

In GitLab by @ThomasDowrick on Feb 1, 2019, 10:02

We had previously thought that we were restricted to Windows in order to have compatibility with the StealthStation. However, after looking into the build process, we should now be able to work on any OS by setting the correct flags.

I'd agree that for the immediate future, probably best to stick with Windows, but maybe once we address the main outstanding issues we can reevaluate.

tdowrick commented 3 years ago

In GitLab by @TomVercauteren on Feb 3, 2019, 09:30

Agreed on needing to be very cautious on changing OS... Anyway, it seems that StealthLink should work with PLUS on linux but they say it is not tested. http://perk-software.cs.queensu.ca/plus/doc/nightly/user/DeviceStealthLink.html

One more reason to be cautious.

tdowrick commented 3 years ago

In GitLab by @RolandGuichard on Feb 4, 2019, 10:18

Next attempts:

tdowrick commented 3 years ago

In GitLab by @AnastasisGeorgoulas on Feb 8, 2019, 17:30

Compiling PLUS Server on the Alienware fails. We've narrowed it down to the VTK build and this particular subproject:

3>  Project "C:\PLUS-bin\Deps\vtk-bin\ALL_BUILD.vcxproj" (1) is building "C:\PLUS-bin\Deps\vtk-bin\GUISupport\Qt\QVTKWidgetPlugin.vcxproj" (5) on node 1 (default targets).
3>  PrepareForBuild:
3>    Creating directory "QVTKWidgetPlugin.dir\Release\".
3>  InitializeBuildStatus:
3>    Creating "QVTKWidgetPlugin.dir\Release\QVTKWidgetPlugin.unsuccessfulbuild" because "AlwaysCreate" was specified.
3>  CustomBuild:
3>    Generating moc_Q4VTKWidgetPlugin.cpp
3>    Generating moc_TARGET.cpp
3>    moc: C:/PLUS-bin/Deps/vtk/GUISupport/Qt/TARGET: No such file
3>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB6006: "cmd.exe" exited with code 1. [C:\PLUS-bin\Deps\vtk-bin\GUISupport\Qt\QVTKWidgetPlugin.vcxproj]
3>  Done Building Project "C:\PLUS-bin\Deps\vtk-bin\GUISupport\Qt\QVTKWidgetPlugin.vcxproj" (default targets) -- FAILED.
tdowrick commented 3 years ago

In GitLab by @JonathanShapey on Mar 12, 2019, 10:42

changed due date to March 21, 2019

tdowrick commented 3 years ago

In GitLab by @ThomasDowrick on Mar 21, 2019, 11:02

Closing as we have addressed this with the scikit-surgerybk library https://weisslab.cs.ucl.ac.uk/WEISS/SoftwareRepositories/SNAPPY/scikit-surgerybk

tdowrick commented 3 years ago

In GitLab by @ThomasDowrick on Mar 21, 2019, 11:02

closed