Difference between revisions of "Collaboration/VMTK"

From NAMIC Wiki
Jump to: navigation, search
 
(18 intermediate revisions by 2 users not shown)
Line 1: Line 1:
'''Objective:'''
+
{|
 +
|[[Image:ProjectWeek-2007.png|thumb|320px|Return to [[2007_Programming/Project_Week_MIT|Project Week Main Page]] ]]
 +
|[[Image:VmtkSlicerModule.jpg|thumb|300px]]
 +
|[[Image:VmtkRefSys1.jpg|thumb|300px]]
 +
|[[Image:VmtkRefSys2.jpg|thumb|300px]]
 +
|[[Image:VmtkRefSys3.jpg|thumb|300px]]
 +
|[[Image:VmtkRefSys4.jpg|thumb|300px]]
 +
|[[Image:VmtkRefSys5.jpg|thumb|300px]]
 +
|}
  
As a result of the Programming Half Week in SLC, vmtk command-line pipes can be automatically converted in CLI modules for Slicer3.
+
__NOTOC__
However, a few issues still exist, mainly associated with the fact that vmtk is vtk based, and thus it is not MRML aware. This generates the sort of problems described in [[Execution Model Reference Systems]]. Solving coordinate system consistency issues is the first aim of the project during the Boston Programming Week.
+
===Key Investigators===
This part of the project will benefit from the interaction with [[2007_Project_Week_MIT_MRML_Scenes_for_the_Execution_Model]].
+
* Mario Negri Institute: Luca Antiga
 +
* GE: Dan Blezek, Jim Miller
 +
* Isomics: Steve Piper
  
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, which could be potentially useful for other projects, is to create a general Python Execution module
+
<div style="margin: 20px;">
Ultimately the user would write a Python class with
+
 
 +
<div style="width: 27%; float: left; padding-right: 3%;">
 +
 
 +
<h1>Objective</h1>
 +
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
 +
 
 +
</div>
 +
 
 +
<div style="width: 27%; float: left; padding-right: 3%;">
 +
 
 +
<h1>Approach, Plan </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 [[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 (vmtk is primarily a Python module) as it would save I/O operations.
 +
The idea is to create a general Python Execution model. 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 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
 
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.
 
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.
  
In summary, the tasks to be completed for this programming week are
 
* solve last issues with consistency of reference systems and generate a bunch of vmtk CLI modules
 
* exploit Python in Slicer3
 
  
'''Progress:'''
+
</div>
 +
 
 +
<div style="width: 40%; float: left;">
 +
 
 +
<h1>Progress</h1>
 +
 
 +
 
 +
====June 2007 Project Week====
 +
 
 +
Full-fledged CLI GUIs can be generated automatically, now including radio button-based choices and numeric ranges.
  
'''Next Steps:'''
+
With small modifications to Slicer's CommandLineModule infrastructure (not committed yet), Slicer can now spit images
 +
in a "localized" coordinate system aligned with XYZ axes. This is useful for VTK-based code that is not RAS aware but instead
 +
uses vtkImageData (with no transform information attached). Input fiducials, ROIs and models are transformed to the localized
 +
coordinate system before being sent to the command line. After the execution, Slicer loads the results transforming them back
 +
to RAS.
  
'''Key Investigators:'''
+
This greatly simplified the interaction between vmtk and Slicer and will be potentially useful to other projects for integrating
*Luca Antiga, Mario Negri Institute
+
existing non-RAS aware code in Slicer.
*Dan Blezek, GE
 
  
'''Publications:'''
+
===References===
  
'''Reference:'''
 
 
http://vmtk.sourceforge.net
 
http://vmtk.sourceforge.net
  
'''Additional Links:'''
+
http://villacamozzi.marionegri.it/~luca/vmtk/doku.php?id=vmtk:screenshots
*4 block ppt
 

Latest revision as of 15:40, 13 July 2007

Home < Collaboration < VMTK
VmtkSlicerModule.jpg
VmtkRefSys1.jpg
VmtkRefSys2.jpg
VmtkRefSys3.jpg
VmtkRefSys4.jpg
VmtkRefSys5.jpg


Key Investigators

  • Mario Negri Institute: Luca Antiga
  • GE: Dan Blezek, Jim Miller
  • Isomics: Steve Piper


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

Approach, Plan

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 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 (vmtk is primarily a Python module) as it would save I/O operations. The idea is to create a general Python Execution model. 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

Full-fledged CLI GUIs can be generated automatically, now including radio button-based choices and numeric ranges.

With small modifications to Slicer's CommandLineModule infrastructure (not committed yet), Slicer can now spit images in a "localized" coordinate system aligned with XYZ axes. This is useful for VTK-based code that is not RAS aware but instead uses vtkImageData (with no transform information attached). Input fiducials, ROIs and models are transformed to the localized coordinate system before being sent to the command line. After the execution, Slicer loads the results transforming them back to RAS.

This greatly simplified the interaction between vmtk and Slicer and will be potentially useful to other projects for integrating existing non-RAS aware code in Slicer.

References

http://vmtk.sourceforge.net

http://villacamozzi.marionegri.it/~luca/vmtk/doku.php?id=vmtk:screenshots