Leadership:SlicerIGT 2007

From NAMIC Wiki
Revision as of 12:20, 13 October 2007 by Kikinis (talk | contribs) (New page: October 12 =Noby= *I agree with Ron. See attached thumb|150px|Slicer linked to commercial software file showing my work in Japan to link Slicer with a commercial ...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
Home < Leadership:SlicerIGT 2007

October 12

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.