Difference between revisions of "AHM2010:DiffusionDatatypesBreakout"
From NAMIC Wiki
| Line 2: | Line 2: | ||
*How should the NAMIC-Kit handle new upcoming diffusion datatypes? | *How should the NAMIC-Kit handle new upcoming diffusion datatypes? | ||
*Discussion of | *Discussion of | ||
| − | ** | + | ** Varieties of diffusion datatypes |
** Slicer data model for visualization of new datatypes | ** Slicer data model for visualization of new datatypes | ||
** File formats for interoperability of analysis tools | ** File formats for interoperability of analysis tools | ||
| − | Overall | + | Overall Conclusions |
* All attendees agree Slicer3 generic data model should enable plugins of new data for diffusion visualization. This will be very useful to all attendees. | * All attendees agree Slicer3 generic data model should enable plugins of new data for diffusion visualization. This will be very useful to all attendees. | ||
* All attendees agree vtkPolyData for fibers, and nrrd for volumes, are sufficiently generic to store all datatypes we can imagine. | * All attendees agree vtkPolyData for fibers, and nrrd for volumes, are sufficiently generic to store all datatypes we can imagine. | ||
| Line 31: | Line 31: | ||
DATA TYPES LIST (not exhaustive, includes data used by attendees and other well-known models) | DATA TYPES LIST (not exhaustive, includes data used by attendees and other well-known models) | ||
| + | * real spherical harmonic coefficients: vectors but of varying lengths 6 to 100 components, tied to a basis | ||
| + | *two-tensor or mixtures of tensors, of watson functions | ||
| + | *mixture models in general | ||
| + | *PAS vector of coefficients, basis | ||
| + | *Gaussian mixture models - Fisher basis gaussian on sphere | ||
| + | *ball and stick model (Tim Behrens) | ||
| + | *probabilistic tracking -- scalar map | ||
| + | *DSI - volumes full FT of signal | ||
| + | *qball | ||
| + | *(various scalar measures from the above) | ||
FRAMEWORK IDEAS (to enable development of slicer visualization for new data) | FRAMEWORK IDEAS (to enable development of slicer visualization for new data) | ||
| + | * Visualization issue: difficult to implement in current framework (Luke Bloy experience involved duplicating all code from tensors for spherical harmonics). | ||
| + | * Everyone would like to use slicer to look at their data in future | ||
| + | * Data Model Class Abstraction Idea | ||
| + | **overloaded methods/ plugin idea | ||
| + | ** API for new data - how to view it in slicer | ||
| + | ***implement the following methods i.e. display node, scalar computation | ||
| + | *** at this point give me a glyph | ||
| + | *** at this point give me scalars that are relevant | ||
| + | ** Use polydata and add arrays to it for multicomponent data | ||
| + | ** Each data model class knows how to deal with its data | ||
| + | ** Model should ideally be used for volumes/models/fibers | ||
INTEROPERABILITY (file types for cross-program diffusion data I/O) | INTEROPERABILITY (file types for cross-program diffusion data I/O) | ||
| − | + | *current file type is vtkPolyData - named arrays can tag datatypes for future datatype expansion. | |
| + | *nrrd for volumes - for future, allows arbitrary strings/fields if we need to store metadata | ||
| + | * Conclusion is these formats are sufficiently general and can remain the standard for NAMIC interoperability | ||
[http://www.na-mic.org/Wiki/index.php/AHM_2010 Back to NA-MIC AHM 2010] | [http://www.na-mic.org/Wiki/index.php/AHM_2010 Back to NA-MIC AHM 2010] | ||
Revision as of 21:35, 6 January 2010
Home < AHM2010:DiffusionDatatypesBreakoutAgenda
- How should the NAMIC-Kit handle new upcoming diffusion datatypes?
- Discussion of
- Varieties of diffusion datatypes
- Slicer data model for visualization of new datatypes
- File formats for interoperability of analysis tools
Overall Conclusions
- All attendees agree Slicer3 generic data model should enable plugins of new data for diffusion visualization. This will be very useful to all attendees.
- All attendees agree vtkPolyData for fibers, and nrrd for volumes, are sufficiently generic to store all datatypes we can imagine.
- See below for meeting notes.
Logistics:
- Wednesday January 6, 12:30 pm - 1:30 pm
- Location: Amethyst 1
Attendees
- Anuja Sharma
- Alex Yarmarkovitch
- Mahnaz Maddah
- Deepika Mahalingam
- Yundi Shi
- Zohara Cohen
- Martin Styner
- Gopal Veni
- James Malcolm
- Luke Bloy
- Lauren O'Donnell
Meeting Notes
DATA TYPES LIST (not exhaustive, includes data used by attendees and other well-known models)
- real spherical harmonic coefficients: vectors but of varying lengths 6 to 100 components, tied to a basis
- two-tensor or mixtures of tensors, of watson functions
- mixture models in general
- PAS vector of coefficients, basis
- Gaussian mixture models - Fisher basis gaussian on sphere
- ball and stick model (Tim Behrens)
- probabilistic tracking -- scalar map
- DSI - volumes full FT of signal
- qball
- (various scalar measures from the above)
FRAMEWORK IDEAS (to enable development of slicer visualization for new data)
- Visualization issue: difficult to implement in current framework (Luke Bloy experience involved duplicating all code from tensors for spherical harmonics).
- Everyone would like to use slicer to look at their data in future
- Data Model Class Abstraction Idea
- overloaded methods/ plugin idea
- API for new data - how to view it in slicer
- implement the following methods i.e. display node, scalar computation
- at this point give me a glyph
- at this point give me scalars that are relevant
- Use polydata and add arrays to it for multicomponent data
- Each data model class knows how to deal with its data
- Model should ideally be used for volumes/models/fibers
INTEROPERABILITY (file types for cross-program diffusion data I/O)
- current file type is vtkPolyData - named arrays can tag datatypes for future datatype expansion.
- nrrd for volumes - for future, allows arbitrary strings/fields if we need to store metadata
- Conclusion is these formats are sufficiently general and can remain the standard for NAMIC interoperability
