Issues with Slicer 4.10

[tdowrick]

In GitLab by @AnastasisGeorgoulas on Jul 29, 2019, 17:13

This issue is for recording what we have tried with Slicer 4.10 and what problems we have encountered.

Generally: We started off by trying to work with version 4.10. Among other advantages, this version offers an improved rendering pipeline, supports showing two volumes at the same time, and benefits from newer module versions (in particular, any fixes to modules only seem to be applied to the latest stable version and the nightly build, not earlier versions). During development, we came across some problems that required us to use Slicer 4.8.

Differences between versions

Switching between different versions is not always trivial. For example:

• Some functionality in 4.10 may not exist in 4.8.
• Constants and functions change names between versions.
• Some widgets do not have coded names in their 4.8 versions, making it hard to add them to the slicelet except by figuring out their exact order in the parent widget (and this order changes when something is copied to the slicelet).
• We could not find a simple way to get the Slicer version programmatically, which would help keep the code cleaner.

That said, the code as it is at the moment includes some workarounds to make it compatible with both versions, although it has not been thoroughly tested with 4.10, especially the more recent additions (e.g. anything to do with the neurostimulation).

Problems with Slicer 4.10

There are two main reasons why we decided to switch back to 4.8.

1. We couldn’t load the image from the Stealth. We tried doing it through the PlusRemote module and that didn’t work (we just never got any data, if I remember right). We also tried manually creating and sending commands to PLUS Server from Slicer (this wasn’t possible initially because of some missing methods but they fixed it). However, the module logic was also missing some methods to inspect the results. I submitted a fix for that, but I must have missed something because we still couldn’t get it to work.

2. We were getting an error during the reconstruction. This only appeared with the particular version of PLUS that we have been using (2.6) and Slicer 4.10 (it works in 4.8). From looking around, it seemed that the bug had maybe been fixed in later versions of PLUS, but we did not have a newer version that we could use: they had stopped releasing precompiled versions of PLUS with StealthLink support, and we never managed to build it ourselves despite multiple attempts. Version 2.8 of PLUS has recently been released with support for StealthLink, so perhaps this is resolved.

[tdowrick]

In GitLab by @DavidPerez-Suarez on Jul 29, 2019, 17:57

At this stage of the project and so close to the first real case (6th of August) I recommend to focus on Slicer 4.8 and if there's time afterwards to upgrade it to 4.10.

[tdowrick]

In GitLab by @MattClarkson on Jul 29, 2019, 18:08

Regarding: "US delay. We don't believe is to do with the version of Slicer, but with the IGTLink. The analysis that Anastasis did on Thursday shows that.",

What's the evidence?

[tdowrick]

In GitLab by @AnastasisGeorgoulas on Jul 29, 2019, 19:02

We measured the time taken to read a frame, and it was about 150ms. Most of that seems to be spent on a different thread (the pyIGTLink server) rather than the reading itself. This is consistent with what we had observed (can get good performance up to about 7 fps, more than that gives a delay).

We tried that in various configurations, cutting out either Slicer or PLUS (we need one of them so that the server starts sending data), and the result was the same. I guess it's theoretically possible that both of them are faulty, but this timing was taken from within scikitsurgery-bk, and it matched the diagnostics from both Slicer and PLUS - can effectively get only around 6-7 fps, regardless of how much we ask for.