Difference between revisions of "2009 Winter Project Week vtkITK Pipeline"
(New page: {| |thumb|320px|Return to [[2009_Winter_Project_Week|Project Week Main Page ]] |} __NOTOC__ ===Key Investigators=== * Steve Pieper, Isomics, Inc. * Jim Miller, ...) |
|||
| Line 41: | Line 41: | ||
<h1>Progress</h1> | <h1>Progress</h1> | ||
| + | Several discussions were held with various developers and other experts and we decided the approaches given in the example would work pretty well for image filter use cases. The approach shown here has the advantage that image metadata is handled explicitly, making it easier to understand and debug than approaches that rely on macros or helper classes. A disadvantage is the need for a memcopy in the current implementations. We will continue to consider ways to avoid this. | ||
</div> | </div> | ||
Latest revision as of 20:24, 31 January 2009
Home < 2009 Winter Project Week vtkITK Pipeline Return to Project Week Main Page |
Key Investigators
- Steve Pieper, Isomics, Inc.
- Jim Miller, GE
Objective
There are several places in slicer where we need to use ITK classes in the context of interactive 3D visualizations implemented as VTK pipelines. Examples include the LevelTracing and Wand effects in the Editor Module and the DistanceTransformModel Module.
Historically, the vtkITK library in slicer, originally developed in the ITK project, has provided a framework for this by implementing generic superclasses to connect the pipelines. However this interface is not actively developed and it recent tests indicate that pipelines are not correctly updated using the current builds of VTK and ITK (see example below).
The goal of this project is to develop a good standard pattern for classes that use ITK in their implementation.
Approach, Plan
We will review some recently written classes including the vtkITKDistanceTransform and vtkITKWandImageFilter to see if they can be used as a template.
Questions:
- these classes construct the itk image directly from the buffer pointer - should that be encapsulated for general use (perhaps with existing importer or exporter classes)?
- the final step in the execute function is a memcpy - is there a way to avoid this?
We also need to write some tests to ensure that these pipeline mechanisms keep functioning as new versions of VTK and ITK are rolled out.
Progress
Several discussions were held with various developers and other experts and we decided the approaches given in the example would work pretty well for image filter use cases. The approach shown here has the advantage that image metadata is handled explicitly, making it easier to understand and debug than approaches that rely on macros or helper classes. A disadvantage is the need for a memcopy in the current implementations. We will continue to consider ways to avoid this.
########### test script ############# set ellip [vtkImageEllipsoidSource New] set gad [vtkITKGradientAnisotropicDiffusionImageFilter New] $gad SetInput [$ellip GetOutput] $ellip SetInValue 200 [$gad GetOutput] Update puts [[$gad GetOutput] GetScalarRange] puts [$ellip GetMTime] puts [[$gad GetOutput] GetMTime] $ellip SetInValue 100 [$gad GetOutput] Update puts [[$gad GetOutput] GetScalarRange] puts [$ellip GetMTime] puts [[$gad GetOutput] GetMTime] ######## sample session ####### (Slicer3-build) 66 % source /pieper/hacks/vtkITK.tcl 0.0 200.0 5323593 5323959 0.0 200.0 5323966 5323959
