Difference between revisions of "Projects/Slicer3/2007 Project Week QDEC Slicer3 Integration"

From NAMIC Wiki
Jump to: navigation, search
 
Line 4: Line 4:
 
|[[Image:Slicer3ReadMGHVolumeEncodedScalars.jpg|thumb|320px|Volume encoded scalars: FreeSurfer versus Slicer ]]
 
|[[Image:Slicer3ReadMGHVolumeEncodedScalars.jpg|thumb|320px|Volume encoded scalars: FreeSurfer versus Slicer ]]
 
|-
 
|-
|[[Image:Slicer3QDECSurfaceAndGUI.jpg|thumb|640px|Slicer3 with average left pial surface with curv + stats overlay, showing QDEC module GUI]]
+
|[[Image:Slicer3QDECSurfaceAndGUI.jpg|thumb|300px|Slicer3 with average left pial surface with curv + stats overlay, showing QDEC module GUI]]
 
|[[Image:Slicer3QDECPlot.jpg|thumb|240px|Plot window generated in Slicer3]]
 
|[[Image:Slicer3QDECPlot.jpg|thumb|240px|Plot window generated in Slicer3]]
 
|}
 
|}

Latest revision as of 18:38, 29 June 2007

Home < Projects < Slicer3 < 2007 Project Week QDEC Slicer3 Integration
Volume encoded scalars: FreeSurfer versus Slicer
Slicer3 with average left pial surface with curv + stats overlay, showing QDEC module GUI
Plot window generated in Slicer3


Key Investigators

  • BWH Nicole Aucoin
  • MGH: Kevin Teich, Nick Schmansky, Doug Greve, Gheorghe Postelnicu
  • Isomics: Steve Pieper

Objective

We are incorporating some of the functionality of the MGH developed Freesurfer front end query tool (QDEC) into Slicer 3, and exploring related issues of how to better integrate Freesurfer and Slicer3.

Approach, Plan

Our approach to the integration is to get the low level functionality in place before the project week (file format reading, picking), and then use the group time to solve GUI issues. The main challenge is in extracting functionality from FreeSurfer in a sustainable and reusable manner.

Our plan for the project week is to first try out calling a stand alone executable binary from the Slicer GUI.

Progress

Preparation

  • volume encoded scalar format reading is done
  • compositing scalars in Slicer3 is done
  • picking points on models allows access to the vertex ids, allowing indexing into data arrays
  • mini-Qdec supplied from MGH to BWH
  • Slicer3 can load user supplied qdec.table.dat

During the Week

  • Refined the GUI elements to mimic QDEC (selectable factors)
  • Interfaced to the mini-QDEC library to set up GLM designs, run them, load results back into Slicer3 (with overlay compositing)
  • Ported the GDF file reader from Slicer2
  • Ported the TCL plotting code from Slicer2

To Do

  • Picking to drive plotting



References

Additional Information

Discussion

  • Slicer will incorporate the basic QDEC functionality:
    • load a user-supplied table of subject data (the qdec.table.dat file)
    • display the available discrete and continous factors, and allow their selection
    • call mri_glmfit binary (through the C++ API, to be supplied)
    • display the resulting data, which will be the fsaverage surface, and overlay data
    • allow selection of a vertex, and display a scatter plot
  • What's a list of issues that need a good working solution?
    • being able to read volume encoced scalar format - done, changes made to vtkMRMLModelStorageNode
    • being able to composite scalars in Slicer3 - done, vtkMRMLModelNode::CompositeScalars (need to save the model in vtk to save the composite in mrml) FreeSurfer versus Slicer
    • picking points on models - use the fiducials interface to get at vertex ids and index into scalar overlays - done, the vtkSlicerViewerWidget class Pick method sets the picked cell ID, vertex ID - check if the Pick succeeded in finding a model node (PickedNodeName != ""), then use it to get the model node, which contains polydata that can be indexed using the vertex ID (PickedPointID)
    • FSGDF plotting
  • Identify which parts of this project are:
  1. internal developments, tightly coupled to the MGH environment
  2. features that Slicer3 might have in order to provide some qdec-type functionality to a potentially wider audience (say, BIRN users on windows)
    1. code in slicer for reading mgh file formats (mgz, surfaces, annotations, etc) into ITK and VTK which is duplicated with code used in qdec, scuba, etc.
  3. what common libraries could be shared by both of those efforts.
    1. MGH host a publicly readable svn repository, perhaps called libMGH, where all this stuff would be captured as the "official" reference implementation. MGH internal projects also rely on the library so that other users could be confident that the library is up to date and fully compatible.
  • The core QDEC engine, mri_glmfit, will be supplied as a binary, and C++ interface objects will provide the access to it, and input data loading. Slicer (and our QDEC) will compile against those C++ objects

Back to Project week