Difference between revisions of "Collaboration/VMTK"
| Line 4: | Line 4: | ||
|} | |} | ||
| − | |||
| − | |||
| − | |||
__NOTOC__ | __NOTOC__ | ||
===Key Investigators=== | ===Key Investigators=== | ||
| Line 26: | Line 23: | ||
<h1>Approaches and Challenges </h1> | <h1>Approaches and Challenges </h1> | ||
| − | + | A few issues still exist, mainly associated with the fact that vmtk is vtk based, and thus it is not MRML aware. Problems are described in [[Execution Model Reference Systems | here]]. Solving coordinate system consistency issues will benefit from the interaction with the [[2007_Project_Week_MIT_MRML_Scenes_for_the_Execution_Model | MRML scenes for the Execution model]] project. | |
| − | |||
| − | |||
Following the recent introduction of Python in Slicer3, it is in principle possible to use vmtk directly from Slicer's Python shell. This is would be a nice alternative to calling vmtk from the command line, since vmtk is primarily a Python module. | Following the recent introduction of Python in Slicer3, it is in principle possible to use vmtk directly from Slicer's Python shell. This is would be a nice alternative to calling vmtk from the command line, since vmtk is primarily a Python module. | ||
| − | + | The idea is to create a general Python Execution module. A Python class would be required to have | |
| − | The idea | ||
| − | |||
* a method that spits out the description of the instance variables to be exposed on the GUI, the CLI module way (in this case, instance variables could be wrapped vtk objects or wrapped MRML nodes) | * a method that spits out the description of the instance variables to be exposed on the GUI, the CLI module way (in this case, instance variables could be wrapped vtk objects or wrapped MRML nodes) | ||
* a standard method (e.g. Execute()) that runs the class main functionality | * a standard method (e.g. Execute()) that runs the class main functionality | ||
| Line 47: | Line 40: | ||
====June 2007 Project Week==== | ====June 2007 Project Week==== | ||
| − | + | Automated generation of Slicer3 CLI modules from vmtk command line pipes has been set up, and a few example modules have been generated. | |
====January 2007 Project Half Week==== | ====January 2007 Project Half Week==== | ||
Revision as of 08:11, 25 May 2007
Home < Collaboration < VMTK Return to Project Week Main Page |
|
Key Investigators
- Mario Negri Institute: Luca Antiga
- GE: Dan Blezek
Objective
Integration of vmtk (vmtk.sourceforge.net) into Slicer3 (ground work already done in SLC).
- solve last issues with consistency of reference systems and generate a bunch of vmtk CLI modules
- exploit Python in Slicer3
Approaches and Challenges
A few issues still exist, mainly associated with the fact that vmtk is vtk based, and thus it is not MRML aware. Problems are described in here. Solving coordinate system consistency issues will benefit from the interaction with the MRML scenes for the Execution model project.
Following the recent introduction of Python in Slicer3, it is in principle possible to use vmtk directly from Slicer's Python shell. This is would be a nice alternative to calling vmtk from the command line, since vmtk is primarily a Python module. The idea is to create a general Python Execution module. A Python class would be required to have
- a method that spits out the description of the instance variables to be exposed on the GUI, the CLI module way (in this case, instance variables could be wrapped vtk objects or wrapped MRML nodes)
- a standard method (e.g. Execute()) that runs the class main functionality
Slicer would take care of building the GUI and setting the state of the object on the basis of the XML description before calling Execute.
Progress
June 2007 Project Week
Automated generation of Slicer3 CLI modules from vmtk command line pipes has been set up, and a few example modules have been generated.
January 2007 Project Half Week
