Leadership:SlicerIGT 2007

This is a discussion about the requirements for Slicer for IGT. The blog is in reverse chronological order, most recent on top.

October 18

David

1:30PM

I definitely think that, for clinical trials, you only want one blade to be available. You can't have people trying out different things for different cases. Clinical trials are a separate issue from the research OR time that Noby was describing.

I want to get back to the architectural issue of the modules, however. For reference, this link describes the way that non-CLI modules are currently implemented in Slicer3:

Slicer3:How_to_implement_an_Interactive_Module_GUI

The included instructions for module developers say to add the module initialization code to Slicer3.cxx. From an architectural standpoint, this has to change, and I'm sure that it was always intended that these modules would be initialized in a cleaner fashion.

Gabor

12:49PM

Right: Slicer must support both uses. I want both uses, but never at the same time. The Swiss knife should never appear in the OR in a clinical trial. We often want to reconfig the clinical application in the lab to gain access to the Swiss knife. But this is back in the lab, post surgery. You never want to play with a knife in the OR, right? Once the one blade of the Swiss knife is selected, we want only this blade to remain on the table, the rest of the knife should go back in the drawer when we turn the system back into clinical trial mode. This, I think, is what Will (and Sebastian, David and Csaba) meant, right? --gabor

Csaba

11:14AM

If you have dynamic modules, just like Photoshop plugins, you can load any module run time, including filters.

Will

10:42AM

Noby brings up a good point. However, I think there are two somewhat conflicting uses: 1) as a research platform and 2) as a deployment vehicle. For research, flexibility is imperative. For focused delivery of a medical therapy (or in support of a therapy) the API and application should be finely tuned, simple and hardened. I think we want to create the framework in Slicer so that we can support both uses. Will

Noby

10:22AM

Let me be a devil's advocate based on my real experience...

I was in MR/T operating Slicer for MR-guided ablation of brain tumor. We showed MR thermal map to the surgeons for them to assess the effect of ablation, but they complained it was the thermal map was noisy very difficult to comprehend. During a short break (2-3 minute), I browsed what was available in Slicer for image smoothing and found anisotropic diffusion filter, I believe, originally developed for vessel segmentation.

The result was beautiful and surgeon could comprehend the thermal map better. We did a follow up analysis and found that filter only preserved the true thermal map while removing noises.

My point is there is a benefit of Slicer being swiss army knife with both IGT and medical image processing tools attached together. It actually functions as the bridging mechanism between IGT and medical image processing. Concealing "non-IGT" tool had downside of it and let us be blind to opportunity.

Csaba

10:10AM

I think the point was to not fork Slicer, but offer an easy way to select which modules to compile into the executable. This would be good for most of the Slicer users.

For example a Prostate Intervention will never use the NeuroNav module. Also the NeuroNav module users never need the Prostate Intervention module.

The ideal solution would be to make all the modules dynamic - load them into the memory run-time only if needed. A slimmed down Slicer will start up faster, will use less memory and is more stable.

If a module can't be made dynamic, we could have a CMake option to turn it on or off before compiling.

Ron

8:29AM

I agree with you. That is exactly the issue that we are talking about.

If the gentleman from Synarch feels that he needs a trimmed down and locked down version for a clinical trial, there is nothing in our license that would prevent him from doing that. He will have to do whatever maintenance that is needed for his special version.

However, for the NA-MIC funded work, I think that it is critical, that we have only one Slicer. I am not opposed to have an initial presentation that does not expose all of Slicer and the layout mechanism could be expanded to support this.

October 15

Sebastian

I'm definitely on the same page as David here actually. The hard-coded options and the huge list of #ifdef is getting hard to maintain; every once in a while I give a quick pass at Slicer3.cxx to fix the #ifdef, since there are at least 4 or 5 places to modify *per module* in Slicer3.cxx. Module maintainers can't really be blamed here, this solution is definitely not obvious unless you are familiar with Slicer3 initialization code: we could/should change that, especially now that we have sampled a decent variety of modules and can formalize the API to initialize them even tighter.

Now this was OK "so far" for the vast majority of Slicer3 users/developers but a few people have either adopted a different way to build Slicer3, or want to build on top of a "light Slicer3"; this has been my case for a while now, I try to help support the team when a GUI question arises, and I'd like to update Slicer3 SVN, build it "lean-and-mean", without the modules (especially the user-generated one which I trust), and fire my debugger. I actually recently added BUILD_MODULES and BUILD_CLI that can be turned off to get that "lightweight" Slicer3, shrinking my build tree from 2.5 GB to 500 MB: http://massmail.spl.harvard.edu/pipermail/slicer-devel/2007/001866.html

Very often though, Slicer3.cxx won't compile for me because of a missing #ifdefs, and I can relate to David when he expresses his concern about this file. This is, however, very much in the realm of what CMake can fix; a decent macro could be used to declare a module (and turn it on/off) and auto-generate the code necessary to initialize it. All those calls could then be compounded into a configured CXX file, compiled and linked against Slicer3.cxx, etc, reducing the size of this file to, indeed, 200 lines.

October 13

Ron

We should really explore the layout capability in Slicer3 as a way to present a simplified appearance in a clinical trial. We could even have a pop up that gives a warning if people want to go to a different layout. Something like:
Are you sure you want to do that?
If you switch to a different layout, you are not compliant with the clinical trial anymore!

October 12

David

There are a couple issues that I would like to address. One is architectural and the other is functional, but they both tie in together. Please bear with me, because it isn't until the very end that I get into the "multiple slicers" issue.

The architectural issue has to do with the current "Slicer3.cxx" file that comprises the front-end. It is absolutely full of hard-coded options relating to the modules. These options really should be controlled by CMake instead, and the module-specific code in Slicer3.cxx should be moved into separate files. This would reduce Slicer3.cxx to only 200 or so lines of code (instead of the current 2000 lines) which would be ideal. It would also make it easier for people to see what they have to do to add new modules.

The functional issue is that for clinical trials, if we cannot have our own front-end, then we at least want to be able to build a Slicer that only contains the relevant modules and GUI elements. This simplifies the training, decreases load time, and makes for a better technology demonstration.

Most of the hard work here has already been done: Slicer is exceedingly modular, various GUI elements can be hidden, etc. It's just a matter of improving the configurability via CMake, and tracking the dependencies between modules at build-time.

As for the multiple slicer front-ends, it has already been stated that we are not asking for a large number of new front-ends, if everyone doing IGT comes together we might be able to reduce our requirements to a couple new GUI layouts.

Will

It's good to have David on board. If I remember correctly from some past conversations, one of David's concerns was customizing the GUI. As it stands now, Slicer may not support the level of customization that David desires. It would be worth revisiting the Slicer GUI framework to see if we can't add additional flexibility. I'd like to hear (next engr tcon?) some discussion on this from Wendy, Sebastien and Stephen.

Gabor

I am inviting our David Gobbi into this discussion. As you may know, we are gearing up to multi-center clinical trials with an interventional robot system (MRI guided prostate biopsy) to run under Slicer. (David is our lead system architect, Csaba Csoma, also copied, is the software systems engineer who makes all the wonders actually happen.) The system, including Slicer and the robot, will be operated by techs and radiologists. We will not be able to ship an engineer with every system we replicate for clinical collaborators. This brings on some aspects that probably no Slicer user has faced before. David can explain the technical implications much more eloquently...

Noby

• I agree with Ron. See attached
  

  Slicer linked to commercial software
  file showing my work in Japan to link Slicer with a commercial navigation system to enjoy strength of Slicer (medical image processing) and stability of the commercial system. This helped me to publish (as scientific contribution!) in 2003 (Hata et al Academic Radiology).

About ctest --- Kevin and Will put a nice set of ctest in IGSTK. They are really nice and they can even test tracker interface. http://public.kitware.com/dashboard.php?name=igstk

One outstanding work to be done in Slicer-IGT is ctest-ing user-software interaction. This should be done once we implement the kwwidget-based workflow mechanism in neuroendoscope. The use of this kwwidget-based workflow was proposed by Sebastian and Stephen, and I love the idea.

I will develop ctest for robots. This will be part Japanese AIST project, and you and I will discuss our plan with Kiyo and Sakuma in our Tokyo meeting before MICCAI. Peter Kazanzides agreed to join our effort.

Initial email by Ron with comments from Will

R: IGT has special needs that we need to address. On the other hand, we can not, and should not compete with the commercial packages on their turf. The most significant value-add that Slicer can offer, are research capabilities. This requires easy access to the full Slicer.
W: Agreed, we want to keep our focus on pushing the limits of technology, and creating an environment where research can take place. There is a mistaken notion that research tools are inherently slow and unstable. Using test driven development, extreme programming, and designing appropriate flexible frameworks, this is not necessarily true anymore. We see this in VTK and ITK where both tools are used for research as well as embedded in applications, commercial and otherwise. And the same will be true of Slicer because it is built on the same foundation.

R: I am strongly opposed to a zoo of special versions that will inevitably drift apart and will soon become unmanagable. I have been there and do not care to go there again. Of course, I can only speak for NA-MIC, NAC and NCIGT. What people choose to do outside these efforts is none of my business.
W: If we design a framework that can be easily tailored, you get the flexibility and capability of a large system plus the ability to narrow down focus when necessary. Slicer modules are great for this, and I think the overall architecture will serve us well in this direction.

R: As far as the stability and performance are concerned: If I have ever seen an opportunity for the engineering core to be responsive to the needs of the DBP's, this is it. I am not sure that all of the IGT groups are fully aware of what is available to them inside the NA-MIC kit. -The workflow capablities in Slicer are not well documented. -Similarly, I am not sure how much the IGT people know about Ctest as a mechanism to improve stability (who will work with them on this?). -Finally, we should identify what performance issues are at hand and see how to address them (this is again something that will be beneficial to every user of slicer).
W: Workflow is an ongoing research topic. Currently there is good stuff there (e.g., EMSegmenter) and it is very useful at this point. I suggest that the dissemination people team with the engineering core to put some documentation together. Performance concerns can be addressed as long as we get feedback from the DBPs. Often users don't realize that certain algorithms and/or processes can be easily sped up by simple tweaks, or use of different components in a system. In VTK and ITK we routinely see cases where we realize speedups on the order of 10-100x when we work with a customer to make a fast path for a particular application. The hardest thing is to get people to communicate needs, often they give up early without enough communication.

R:Perhaps we should have some discussions in the engineering core about these issues and see if there are solutions that can be addressed with the resources available. I envision activities after the AHM and the release of slicer.
W: Agreed, this sounds good, and it will bring fresh energy to the engineering TCons.