|
Notes |
|
|
(0009012)
|
|
Luis Ibanez
|
|
2007-09-17 08:48
|
|
This is arguable...
It makes sense for a 2D DICOM slice to have a 3x3 direction when it is considered to be a 1-slice 3D image embedded in 3D space.
An application that reads such an image should actually instantiate a type
itk::Image< PixelType, 3> ImageType
not a type
itk::Image< PixelType, 2> ImageType
The 4D case, is a bit more challenging to interpret, although
in this case we will have at hand a 4x4 matrix for storing a
3x3 one, and therefore the only issue is the waste of the 6
other terms that always will be set to zero. |
|
|
|
(0009044)
|
|
Steve Robbins
|
|
2007-09-18 01:55
|
|
I guess this depends on how you interpret the VImageDimension
template parameter in itk::Image. The documentation states
Images are templated over a pixel type (modeling the dependent
variables), and a dimension (number of independent variables).
-- http://www.itk.org/Doxygen32/html/classitk_1_1Image.html [^]
To me, the "number of independent variables" for a planar image is
naturally 2. Though I haven't canvassed other ITK users, I suspect
that is the common interpretation. In support of this, note that (a)
Teem's nrrd separates "dimension" from "space dimension" [1] and (b)
ITK's own GDCM ImageIO class goes out of its way to provide the
3-vector origin and direction cosines for 2D images [2].
[1] http://teem.sourceforge.net/nrrd/format.html [^]
[2] http://www.itk.org/mailman/private/insight-developers/2007-July/009203.html [^]
Time series data is also a problem.
If I have a single slice imaged over time, I would naturally consider
that a 3D image (2 spatial + 1 time). The itk::Image would provide me
with a 3D Origin and cosines, but the third component of these vectors
has nothing to do with the third component of the image dimension
(time).
If I have a volumetric time series -- i.e. 4D data, then I end up with
a 4D Origin and cosines. This is a complete nuisance to do any
world-space math with; e.g. distance or angle measurements. |
|
|
|
(0010259)
|
|
Luis Ibanez
|
|
2008-01-23 16:05
|
|
More discussion is required to find a new configuration that serves all the uses of ITK.
In the meantime, we probably should address the specific concerns of how to use directions in 3D+t image. This could probably be done better by creating helper classes that are aware of the 4D: 3D+t nature of the problem.
SMR: Could you list the use-cases that you need to address in you 3D+t problem ?
Thanks
Luis
|
|