Difference between revisions of "Algorithm:GATech:DWMRI Musings"
Line 24: | Line 24: | ||
'''Algorithm Categorization''' | '''Algorithm Categorization''' | ||
+ | |||
+ | coming soon | ||
+ | |||
+ | '''Beware of the Segmentation Discrimination Paradox''' | ||
coming soon | coming soon |
Revision as of 22:08, 25 July 2007
Home < Algorithm:GATech:DWMRI MusingsDW-MRI Musings
Back to Georgia Tech DW-MRI Geodesic Active Contours.
This page contains a hodge podge of thoughts on Diffusion-Weighted MRI (DW-MRI) processing. From a bird's eye view, the most general question for a DW-MRI data processor is: What clinically relevant information can be leveraged from DW-MRI data and used for scientific and clinical studies? Furthermore, what algorithms, programming constructs, clinical guidance, and training are needed to make this happen? The following are thoughts that may be considered when attempting to answer these questions, in no particular order:
DW-MRI vs DT-MRI
In answering the questions posed above, it is common for people to assume from the onset that we are using terminology related to tensors (i.e. DT-MRI, DTI). The raw data coming out of the scanner is referred to as DW-MRI or DWI. The difference between the "T" and the "W" is that the "T" has undergone a preprocessing step which computes tensors at each voxel which are a function of the original "W" data. Hence, the data resulting from this preprocessing step is referred to at DT-MRI. There are advantages and disadvantages to using this preprocessing tensor construction step. The point here is that when we think about trying to find ways to go from the scanner data to clinical answers, we are talking about going from DW-MRI data to clinical answers. In other words, it is okay to think outside the box and to consider ways in which ellipsoidal constraints arising from the tensor model may be meaningfully relaxed.
Synchronizing Terminology
coming soon
Streamline Ups and Downs
coming soon
Validation Soap Box
When we consider assessing the utility of a particular tool in serving the needs of our clinical customers, we should stop and consider the factors upon which our assessment is based and biased. This is particular important when attempting to validate results in an environment absent of ground truth. In the absence of ground truth, tools are judged according to: visual appeal, reproducibility, user-friendliness, and (if you're shooting for the stars and want something for which there is ground truth) accuracy in diagnosis.
Broadly speaking, each tool consists of four components which contribute toward the utility of the tool: the algorithm, the engineering, the incorporation of clinical knowledge, and the training. It is common to interchange the terms tool and algorithm when assessing the utility of a tool. However, especially in an environment where results are primarily judged by the visual appeal and user-friendliness, this is misleading. The fear here is that streamline-based algorithms which have been around the longest and have enjoyed a great deal of engineering input, clinical guidance, and community training, will somehow be inordinately attended to because the judgment criterion used for these tools is based on these non-algorithmic components. It is useful to ask the question, "If algorithm A had received as much engineering, clinical input, and training as algorithm B, how would this change things?"
Algorithm Categorization
coming soon
Beware of the Segmentation Discrimination Paradox
coming soon
Beware of Mr. Legendre
coming soon