Difference between revisions of "Slicer Interactive Module"

From NAMIC Wiki
Jump to: navigation, search
Line 14: Line 14:
  
 
The standalone program manages surfaces, bounding boxes, and meshes created by the user in linked lists which are updated and displayed through a directly connected GUI.   
 
The standalone program manages surfaces, bounding boxes, and meshes created by the user in linked lists which are updated and displayed through a directly connected GUI.   
 +
  
 
[[image:IaFeMesh-small-102507.jpg]]
 
[[image:IaFeMesh-small-102507.jpg]]
 +
  
  
Line 21: Line 23:
  
 
An interactive module has been added to Slicer called the "MeshingWorkflow Module".  This module performs the same multiple steps as the standalone FE application.  The vast majority of the source code from the original application has been re-used without modification.
 
An interactive module has been added to Slicer called the "MeshingWorkflow Module".  This module performs the same multiple steps as the standalone FE application.  The vast majority of the source code from the original application has been re-used without modification.
 +
 +
  
 
[[image:slicer-meshingworkflow-small-102507.jpg]]
 
[[image:slicer-meshingworkflow-small-102507.jpg]]
 +
  
 
=== Migrating the intermediate steps to MRML ===  
 
=== Migrating the intermediate steps to MRML ===  
  
 
The standalone workflow code uses local lists of surfaces, bounding boxes, and meshes to store intermediate workflow state.  This allows the user to browse forward and backward through the workflow as needed and is an efficient workflow model.  A drawback of this technique (from the slicer integration perspective) is that this information is not stored in the MRML tree during the workflow process.
 
The standalone workflow code uses local lists of surfaces, bounding boxes, and meshes to store intermediate workflow state.  This allows the user to browse forward and backward through the workflow as needed and is an efficient workflow model.  A drawback of this technique (from the slicer integration perspective) is that this information is not stored in the MRML tree during the workflow process.

Revision as of 19:42, 25 October 2007

Home < Slicer Interactive Module

The scope of this subproject is to develop a Slicer3 module for Finite Element modeling. Our approach is to adapt the process and source code from a standalone Finite Element Mesh generation program developed by the MIMX Group at the University of Iowa.

Standalone Program

The IaFeMesh application creates an established workflow consisting of multiple steps:

  • read imagery file
  • create surface from imagery
  • create FE mesh bounding box from the bounds of the surface
  • refine the FE bounding box
  • generate a mesh using projection from the bounding box

The above properties are accomplished through customer KKWidgets which manage the user through workflow using a custom tabbed notebook with image, surface, FE Mesh, and FE Mesh Quality tabs. Under each category, the user works with the corresponding category of data as they perform the workflow that starts with a source image stack and results in a corresponding Mesh of the imaged object.

The standalone program manages surfaces, bounding boxes, and meshes created by the user in linked lists which are updated and displayed through a directly connected GUI.


IaFeMesh-small-102507.jpg


MeshingWorkflow Slicer Module

An interactive module has been added to Slicer called the "MeshingWorkflow Module". This module performs the same multiple steps as the standalone FE application. The vast majority of the source code from the original application has been re-used without modification.


Slicer-meshingworkflow-small-102507.jpg


Migrating the intermediate steps to MRML

The standalone workflow code uses local lists of surfaces, bounding boxes, and meshes to store intermediate workflow state. This allows the user to browse forward and backward through the workflow as needed and is an efficient workflow model. A drawback of this technique (from the slicer integration perspective) is that this information is not stored in the MRML tree during the workflow process.