Difference between revisions of "2009 Winter Project Week ChangeTracker"

From NAMIC Wiki
Jump to: navigation, search
 
(33 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
{|
 
{|
 
|[[Image:NAMIC-SLC.jpg|thumb|320px|Return to [[2009_Winter_Project_Week|Project Week Main Page]] ]]
 
|[[Image:NAMIC-SLC.jpg|thumb|320px|Return to [[2009_Winter_Project_Week|Project Week Main Page]] ]]
−
|[[Image:ChangeTracker_Analysis.png|thumb|280px|ChangeTracker analysis result]]
+
|[[Image:ChangeTracker_Analysis.png|thumb|460px|ChangeTracker analysis result]]
 
|}
 
|}
  
Line 9: Line 9:
  
 
===Key Investigators===
 
===Key Investigators===
−
* Andriy Fedorov (SPL)
+
* Andriy Fedorov, SPL
−
* Marcel Prastawa
+
* Jim Miller, GE
 +
* Karthik Krishnan, Kitware
 +
* Marcel Prastawa, SCI
 +
* Wendy Plesniak, SPL
 +
* Luis Ibanez, Kitware
 +
* Curtis Lisle, Knowledgevis
 +
* Steve Pieper, Isomics
  
 
<div style="margin: 20px;">
 
<div style="margin: 20px;">
Line 19: Line 25:
 
ChangeTracker is a software tool for quantification of the subtle changes in pathology. The module provides a workflow pipeline that combines user input with the medical data. As a result we provide quantitative volumetric measurements of growth/shrinkage together with the volume rendering of the tumor and color-coded visualization of the tumor growth/shrinkage.
 
ChangeTracker is a software tool for quantification of the subtle changes in pathology. The module provides a workflow pipeline that combines user input with the medical data. As a result we provide quantitative volumetric measurements of growth/shrinkage together with the volume rendering of the tumor and color-coded visualization of the tumor growth/shrinkage.
  
−
The objective at this meeting is to determine the status of the Slicer3 components needed for enhanced functionality of ChangeTracker, identify new uses of ChangeTracker, and propose the tentative roadmap for ChangeTracker evolution for the next 6 months.
+
''The objective at this meeting is to determine the status of the Slicer3 components needed for enhanced functionality of ChangeTracker, identify new uses of ChangeTracker, and propose the tentative roadmap for ChangeTracker evolution for the next 6 months.''
 
</div>
 
</div>
  
Line 25: Line 31:
  
 
<h1>Approach, Plan</h1>
 
<h1>Approach, Plan</h1>
 +
We consider the following improvements to ChangeTracker:
 
* Extending the interface to allow analysis of more than two images
 
* Extending the interface to allow analysis of more than two images
 
* Volume rendering of tumor segmentation: visualization and 3d widget for volume cropping
 
* Volume rendering of tumor segmentation: visualization and 3d widget for volume cropping
 
* Using Lightbox for tumor progression visualization
 
* Using Lightbox for tumor progression visualization
 +
* Robustness of initial tumor segmentation. Currently, we use user-guided thresholding. It must be quick, with minimum input from the user. Discuss possible approaches with Marcel, other groups in tumor segmentation research.
 +
* Consider error handling interface issues in execution of an external module (how to properly handle registration errors?)
 
</div>
 
</div>
  
Line 33: Line 42:
  
 
<h1>Progress</h1>
 
<h1>Progress</h1>
−
 
+
* ''Tumor segmentation'':discussed with Luis and Karthik capabilities of LesionSizingToolkit: potentially very useful for improved accuracy of meningioma segmentation. Currently in the process of evaluating the performance of the feature detection on meningioma data
 +
* ''Volume rendering'': worked with Karthik, Will, Curt and Steve on fine-tuning label data volume rendering (see below for details). Evaluated different approaches for visualizing tumor and growth results.
 +
* ''CompareView'' for results visualization: worked with Jim to implement changes to configure the layout with CompareView. Found a workaround to the problem we found in CompareView initialization (thanks, Steve!)
 +
* ''Module error handling'': discussed with Jim changes to the module error handling in Slicer (see below for the proposed modifications)
 +
* ''Time-series analysis'' functionality in Slicer: 5-year development roadmap within NAC project. Following discussions with Wendy and Steve, currently there are no specifications or finalized plans. Advantages: improved memory efficiency and data access. Short term solution -- augmenting ChangeTracker with the additional wizard step to specify the number of timepoints.
 +
* ''Longitudinal lesion analysis in Lupus'': put together a [http://wiki.na-mic.org/Wiki/index.php/ChangeTracker:Lupus_DBP requirements document] with the desired features in ChangeTracker (or ChangeTracker derivative)
 
</div>
 
</div>
  
Line 39: Line 53:
  
 
</div>
 
</div>
 +
 +
==="Customer" projects===
 +
 +
* [http://wiki.na-mic.org/Wiki/index.php/NCI_Evaluating_NA-MIC_Tools_for_Image_Analysis Evaluating NA-MIC tools for image analysis]
 +
* [http://wiki.na-mic.org/Wiki/index.php/2009_Winter_Project_Week:LongitudinalLesions Longitudinal lesion analysis in Lupus]
 +
 +
===Relevant projects of interest===
 +
* [http://wiki.na-mic.org/Wiki/index.php/2009_Winter_Project_Week:LongitudinalLesions Longitudinal lesion analysis]
 +
* [http://wiki.na-mic.org/Wiki/index.php/2009_Winter_Project_Week_Interactive_3D_Widgets_In_Slicer3 3d widgets]
 +
* [http://wiki.na-mic.org/Wiki/index.php/Volume_Rendering Volume rendering]
 +
* [http://wiki.na-mic.org/Wiki/index.php/2009_Winter_Project_Week_Command_Line_Program_Testing Command line program testing]
 +
* [http://wiki.na-mic.org/Wiki/index.php/Lung_Lesion_Sizing_Toolkit Lesion sizing toolkit]
 +
 +
===Volume rendering of label data===
 +
{|
 +
|
 +
We investigated the behavior of volume rendering on the sample data from tumor growth analysis. We identified that it is crucial to use nearest neighbor interpolation for label volume rendering. It appears that the behavior of the opacity mapping function is rather unexplained (see the screenshots):
 +
 +
* although the input label map contains only three intensity values (background 0, shrinking 12 and growth 14), the cut-off location of the opacity mapping for the shrinking label affects rendering
 +
* the results of volume rendering are drastically different from the surface recovered with marching cubes (see the screenshots)
 +
 +
Programmatic initialization of the opacity transfer function for two-label data:
 +
<pre>
 +
  vtkPiecewiseFunction* opacity = vtkPiecewiseFunction::New();
 +
  double* imgRange  =  this->Render_Image->GetPointData()->GetScalars()->GetRange();
 +
  opacity->RemoveAllPoints();
 +
  opacity->AddPoint(imgRange[0], 0.0);
 +
  opacity->AddPoint(min - .1, 0.0);
 +
  opacity->AddPoint(min, 1., .5, 1.);
 +
  opacity->AddPoint(min+0.1, 0.);
 +
  opacity->AddPoint(max-0.1, 0.);
 +
  opacity->AddPoint(max, 1., .5, 1.);
 +
  if (max < imgRange[1]) {
 +
    opacity->AddPoint(max + .1, 0.);
 +
    if (max+.1 < imgRange[1]) {
 +
      opacity->AddPoint(max+.1, 0.);
 +
      opacity->AddPoint(imgRange[1], 0);
 +
    }
 +
  }
 +
  opacity->ClampingOff();
 +
</pre>
 +
 +
The datasets for testing are available [http://wiki.na-mic.org/Wiki/index.php/Image:Rendering_data.zip here], and the transfer function can be seen on the screenshots.
 +
 +
''Current solutions/workarounds we consider: use surface rendering from Marching cubes instead of volume rendering.''
 +
 +
|
 +
{|
 +
|-
 +
|[[Image:transfer_function1.jpg|thumb|300px|Initial transfer function]]
 +
|-
 +
|[[Image:transfer_function2.jpg|thumb|300px|Transfer function showing interpolation artifacts (note the difference in opacity mapping; nearest interpolation is used in both cases)]]
 +
|}
 +
|}
 +
 +
===Module error handling in Slicer===
 +
 +
''Problem'': current implementation of Slicer does not handle the case when a module is executed as a shared library, and fails with an exception. Currently, the user will not be notified about the problem that occured during module execution. Also, if a module is executed from within another module, there is no mechanism to catch the exception and try to determine what was the source of the problem.
 +
 +
''Proposed solution'':
 +
* (1) augment the MRMLCommandLineModuleNode with a ''bool'' flag that will instruct the module logic whether the exception should be re-thrown or not (this can be done only in the same-thread (''ApplyAndWait()'') execution mode)
 +
* (2) add the code in CommandLineModuleLogic to set the execution status to error if an exception occurs
  
 
===References===
 
===References===
 
* E.Konukoglu, W.M.Wells, S.Novellas, N.Ayache, R.Kikinis, P.M.Black, K.M.Pohl. Monitoring Slowly Evolving Tumors. Proc. of 5th IEEE International Symposium on Biomedical Imaging: From Nano to Macro 2008, pp.812-815 [http://www.spl.harvard.edu/pages/Special:PubDB_View?dspaceid=1430 link]
 
* E.Konukoglu, W.M.Wells, S.Novellas, N.Ayache, R.Kikinis, P.M.Black, K.M.Pohl. Monitoring Slowly Evolving Tumors. Proc. of 5th IEEE International Symposium on Biomedical Imaging: From Nano to Macro 2008, pp.812-815 [http://www.spl.harvard.edu/pages/Special:PubDB_View?dspaceid=1430 link]

Latest revision as of 17:12, 9 January 2009

Home < 2009 Winter Project Week ChangeTracker
Return to Project Week Main Page
ChangeTracker analysis result



Key Investigators

  • Andriy Fedorov, SPL
  • Jim Miller, GE
  • Karthik Krishnan, Kitware
  • Marcel Prastawa, SCI
  • Wendy Plesniak, SPL
  • Luis Ibanez, Kitware
  • Curtis Lisle, Knowledgevis
  • Steve Pieper, Isomics

Objective

ChangeTracker is a software tool for quantification of the subtle changes in pathology. The module provides a workflow pipeline that combines user input with the medical data. As a result we provide quantitative volumetric measurements of growth/shrinkage together with the volume rendering of the tumor and color-coded visualization of the tumor growth/shrinkage.

The objective at this meeting is to determine the status of the Slicer3 components needed for enhanced functionality of ChangeTracker, identify new uses of ChangeTracker, and propose the tentative roadmap for ChangeTracker evolution for the next 6 months.

Approach, Plan

We consider the following improvements to ChangeTracker:

  • Extending the interface to allow analysis of more than two images
  • Volume rendering of tumor segmentation: visualization and 3d widget for volume cropping
  • Using Lightbox for tumor progression visualization
  • Robustness of initial tumor segmentation. Currently, we use user-guided thresholding. It must be quick, with minimum input from the user. Discuss possible approaches with Marcel, other groups in tumor segmentation research.
  • Consider error handling interface issues in execution of an external module (how to properly handle registration errors?)

Progress

  • Tumor segmentation:discussed with Luis and Karthik capabilities of LesionSizingToolkit: potentially very useful for improved accuracy of meningioma segmentation. Currently in the process of evaluating the performance of the feature detection on meningioma data
  • Volume rendering: worked with Karthik, Will, Curt and Steve on fine-tuning label data volume rendering (see below for details). Evaluated different approaches for visualizing tumor and growth results.
  • CompareView for results visualization: worked with Jim to implement changes to configure the layout with CompareView. Found a workaround to the problem we found in CompareView initialization (thanks, Steve!)
  • Module error handling: discussed with Jim changes to the module error handling in Slicer (see below for the proposed modifications)
  • Time-series analysis functionality in Slicer: 5-year development roadmap within NAC project. Following discussions with Wendy and Steve, currently there are no specifications or finalized plans. Advantages: improved memory efficiency and data access. Short term solution -- augmenting ChangeTracker with the additional wizard step to specify the number of timepoints.
  • Longitudinal lesion analysis in Lupus: put together a requirements document with the desired features in ChangeTracker (or ChangeTracker derivative)


"Customer" projects

Relevant projects of interest

Volume rendering of label data

We investigated the behavior of volume rendering on the sample data from tumor growth analysis. We identified that it is crucial to use nearest neighbor interpolation for label volume rendering. It appears that the behavior of the opacity mapping function is rather unexplained (see the screenshots):

  • although the input label map contains only three intensity values (background 0, shrinking 12 and growth 14), the cut-off location of the opacity mapping for the shrinking label affects rendering
  • the results of volume rendering are drastically different from the surface recovered with marching cubes (see the screenshots)

Programmatic initialization of the opacity transfer function for two-label data: 

  vtkPiecewiseFunction* opacity = vtkPiecewiseFunction::New();
  double* imgRange  =   this->Render_Image->GetPointData()->GetScalars()->GetRange();
  opacity->RemoveAllPoints();
  opacity->AddPoint(imgRange[0], 0.0);
  opacity->AddPoint(min - .1, 0.0);
  opacity->AddPoint(min, 1., .5, 1.);
  opacity->AddPoint(min+0.1, 0.);
  opacity->AddPoint(max-0.1, 0.);
  opacity->AddPoint(max, 1., .5, 1.);
  if (max < imgRange[1]) {
    opacity->AddPoint(max + .1, 0.);
    if (max+.1 < imgRange[1]) {
      opacity->AddPoint(max+.1, 0.);
      opacity->AddPoint(imgRange[1], 0);
    }
  }
  opacity->ClampingOff();

The datasets for testing are available here, and the transfer function can be seen on the screenshots.

Current solutions/workarounds we consider: use surface rendering from Marching cubes instead of volume rendering.

Initial transfer function
Transfer function showing interpolation artifacts (note the difference in opacity mapping; nearest interpolation is used in both cases)

Module error handling in Slicer

Problem: current implementation of Slicer does not handle the case when a module is executed as a shared library, and fails with an exception. Currently, the user will not be notified about the problem that occured during module execution. Also, if a module is executed from within another module, there is no mechanism to catch the exception and try to determine what was the source of the problem.

Proposed solution:

  • (1) augment the MRMLCommandLineModuleNode with a bool flag that will instruct the module logic whether the exception should be re-thrown or not (this can be done only in the same-thread (ApplyAndWait()) execution mode)
  • (2) add the code in CommandLineModuleLogic to set the execution status to error if an exception occurs

References

  • E.Konukoglu, W.M.Wells, S.Novellas, N.Ayache, R.Kikinis, P.M.Black, K.M.Pohl. Monitoring Slowly Evolving Tumors. Proc. of 5th IEEE International Symposium on Biomedical Imaging: From Nano to Macro 2008, pp.812-815 link
Retrieved from "https://www.na-mic.org/w/index.php?title=2009_Winter_Project_Week_ChangeTracker&oldid=34792"