2011 Winter Project Week:Breakout Multi-Image Engineering - Revision history

Kikinis: /* Background */

2011-01-10T17:25:28Z

Background

Aylward: /* The Need */

2011-01-09T17:16:29Z

The Need

Aylward: /* Sharing */

2011-01-09T17:16:02Z

Sharing

Aylward: /* Processing */

2011-01-09T17:14:36Z

Processing

Aylward: /* Background */

2011-01-09T17:11:26Z

Background

Aylward: /* I/O */

2011-01-09T17:09:42Z

I/O

Aylward: /* Background */

2011-01-09T17:06:38Z

Background

Kikinis: /* Display */

2011-01-07T14:31:42Z

Display

Kikinis: /* Processing */

2011-01-05T02:47:03Z

Processing

Lasso: Added: other node types should be supported as well

2011-01-04T16:30:32Z

Added: other node types should be supported as well

@@ Line 9: / Line 9: @@
 =Background=
-Increasingly, we have data in slicer which are multi something. Examples are:
+Increasingly, we have data in in individual subjects in slicer which are multi something. Examples are:
 *multi-channel (T1, T2, flair, dual echo, etc.)
 *DWI
 *rgb and other multi-channel images
 *time series, including DCE, cardiac cycle, follow-up studies in cancer, multiple intra-procedural volumes (with potential translation, rotation, deformation)
-*multiple subjects for atlas formation / population studies
+*multiple subjects for atlas formation / population studies ?
-*results from processing using different parameters
+*results from processing using different parameters ?
 =Current State=

@@ Line 45: / Line 45: @@
 *Non-image nodes?
 *May point to data on disk without immediately loading it, e.g., description of sequences/sets of images to be processed
 ==Display==

← Older revision		Revision as of 17:16, 9 January 2011
Line 54:		Line 54:
	*Registration: where does it fit? should we provide capability to include transformation assigned to each timepoint/channel? rigid/non-rigid? If yes, probably we should allow to access the original data, probably storing resampled data only is not a good option.		*Registration: where does it fit? should we provide capability to include transformation assigned to each timepoint/channel? rigid/non-rigid? If yes, probably we should allow to access the original data, probably storing resampled data only is not a good option.
	**Generalize eddy current correction for general purpose multi-data fusion? Same subject affine, multiple points. Add N4 bias correction?		**Generalize eddy current correction for general purpose multi-data fusion? Same subject affine, multiple points. Add N4 bias correction?
−	~~==Sharing==~~
−	*Should be able to maintain the grouping of data for distribution to others
−	**Unit = collection of MRML files? (e.g., an xcat file is a standard format to describe results of a database search - supported by XNAT and MIDAS)

← Older revision		Revision as of 17:14, 9 January 2011
Line 54:		Line 54:
	*Registration: where does it fit? should we provide capability to include transformation assigned to each timepoint/channel? rigid/non-rigid? If yes, probably we should allow to access the original data, probably storing resampled data only is not a good option.		*Registration: where does it fit? should we provide capability to include transformation assigned to each timepoint/channel? rigid/non-rigid? If yes, probably we should allow to access the original data, probably storing resampled data only is not a good option.
	**Generalize eddy current correction for general purpose multi-data fusion? Same subject affine, multiple points. Add N4 bias correction?		**Generalize eddy current correction for general purpose multi-data fusion? Same subject affine, multiple points. Add N4 bias correction?
		+	==Sharing==
		+	*Should be able to maintain the grouping of data for distribution to others
		+	**Unit = collection of MRML files? (e.g., an xcat file is a standard format to describe results of a database search - supported by XNAT and MIDAS)

@@ Line 15: / Line 15: @@
 *time series, including DCE, cardiac cycle, follow-up studies in cancer, multiple intra-procedural volumes (with potential translation, rotation, deformation)
 *multiple subjects for atlas formation / population studies
 =Current State=

@@ Line 43: / Line 43: @@
 *We should have a single module to organize the data. DICOM to nrrd is a good start, but we need to be able to handle separate T1 and T2 acquisitions as well. We also need to be able to handle non-dicom data. Perhaps something like: load all data into slicer and associate them inside slicer in a special module. Write out as a single nrrd file.
 *Non-image nodes?
 ==Display==
 *We should create a single visualization infrastructure to handle multi data: compare viewers, rgb channels, time series movies: equivalent slice viewers and 3D viewers

@@ Line 24: / Line 24: @@
 *In the 4D display module, a movie player like capability exists
 *The dti infrastructure allows the display of derived scalar values such as FA and color by orientation
 ==Existing Processing capabilities==
 Multi volumes are processed in Slicer in specialized ways.

← Older revision		Revision as of 02:47, 5 January 2011
Line 46:		Line 46:
	*Common api for processing: EM segmentation, pharmacokinetic models, DWI filtering, tensor estimation should all plug into the data in the same way.		*Common api for processing: EM segmentation, pharmacokinetic models, DWI filtering, tensor estimation should all plug into the data in the same way.
	*Registration: where does it fit? should we provide capability to include transformation assigned to each timepoint/channel? rigid/non-rigid? If yes, probably we should allow to access the original data, probably storing resampled data only is not a good option.		*Registration: where does it fit? should we provide capability to include transformation assigned to each timepoint/channel? rigid/non-rigid? If yes, probably we should allow to access the original data, probably storing resampled data only is not a good option.
		+	**Generalize eddy current correction for general purpose multi-data fusion? Same subject affine, multiple points. Add N4 bias correction?

@@ Line 35: / Line 35: @@
 =The Need=
 All of the current examples are special cases. If we can generalize those into a single architecture for multi data, there would be a lot of potential for cross-benefits. We need a common engineering and UI philosophy for everybody who is working on these topics.
 ==I/O==
 *We should have a single module to organize the data. DICOM to nrrd is a good start, but we need to be able to handle separate T1 and T2 acquisitions as well. We also need to be able to handle non-dicom data. Perhaps something like: load all data into slicer and associate them inside slicer in a special module. Write out as a single nrrd file.
 ==Display==
 *We should create a single visualization infrastructure to handle multi data: compare viewers, rgb channels, time series movies: equivalent slice viewers and 3D viewers
@@ Line 43: / Line 45: @@
 ==Processing==
 *Common api for processing: EM segmentation, pharmacokinetic models, DWI filtering, tensor estimation should all plug into the data in the same way.
-* Registration: where does it fit? should we provide capability to include transformation assigned to each timepoint/channel? rigid/non-rigid? If yes, probably we should allow to access the original data, probably storing resampled data only is not a good option.
+*Registration: where does it fit? should we provide capability to include transformation assigned to each timepoint/channel? rigid/non-rigid? If yes, probably we should allow to access the original data, probably storing resampled data only is not a good option.