Difference between revisions of "2011 Winter Project Week:DTIRegistrationWizard"
| Line 33: | Line 33: | ||
<h3>Progress</h3> | <h3>Progress</h3> | ||
*One issue is that output of one module call is input of other call, i.e. not all inputs are defined a priori when module is launched. | *One issue is that output of one module call is input of other call, i.e. not all inputs are defined a priori when module is launched. | ||
| − | *possible mechanism: new CLM with merged XML and .cxx code. Then prune extraneous options | + | *possible mechanism: new CLM with merged XML and .cxx code. Then prune extraneous options -> requires new .cxx that copies efforts and violates modular design |
| − | *possible mechanism: BatchMakeWrapper: XML wrapper to call module multiple times -> | + | *possible mechanism: BatchMakeWrapper: XML wrapper to call module multiple times -> difficult to adapt to input/output dependencies |
| − | *possible mechanism: Python Scriptable Module | + | *possible mechanism: Chain Module functionality -> no longer supported |
| + | *possible mechanism: Python Scriptable Module -> currently best bet | ||
</div> | </div> | ||
</div> | </div> | ||
Revision as of 23:51, 12 January 2011
Home < 2011 Winter Project Week:DTIRegistrationWizard
DTI Registration & Resampling Wizard
Key Investigators
- BWH: Dominik Meier, Francois Budin
- UIowa: Hans Johnson, Mark Scully
Objective
This project intends to build a dedicated module/wizard for the common case of registering and resampling a DTI image set to a structural reference scan, commonly a high-resolution T1.
Approach, Plan
The algorithms for the necessary processing (registration, sub/supersampling, DTI estimation, DTI resampling) already exist within Slicer. But the parameters and GUIs of the individual modules are non-intuitive and not readily accessible to the clinician researcher. We therefore seek a wizard module that compiles the main pipeline and default settings into a single GUI. This is a "DTI registration light" that will not offer the full range of customization available in the individual modules and hence is not expected to work on the full spectrum of possible case scenarios.
- input: DWI volume or DTI volume incl. baseline and mask
- output: Affine+BSpline registration transform, resampled DTI volume
- use the BRAINSfit module for registering the DTI baseline to the T1 directly
- use the masking option avail. in BRAINSfit. Masks for the moving image is derived from the DTI estimation; mask for the fixed image from the same image sent through a preliminary affine registration
- resampling of the DTI is done via the main algorithm in the Resample DTI Volume module
Progress
- One issue is that output of one module call is input of other call, i.e. not all inputs are defined a priori when module is launched.
- possible mechanism: new CLM with merged XML and .cxx code. Then prune extraneous options -> requires new .cxx that copies efforts and violates modular design
- possible mechanism: BatchMakeWrapper: XML wrapper to call module multiple times -> difficult to adapt to input/output dependencies
- possible mechanism: Chain Module functionality -> no longer supported
- possible mechanism: Python Scriptable Module -> currently best bet
