MantisBT - ITK
View Issue Details
0005573ITKpublic2007-08-24 22:512010-10-26 05:57
Steve Robbins 
Mathieu Malaterre 
normalmajoralways
assignedopen 
 
 
0005573: Image::DirectionType should be Nx3 rather than NxN
Currently, ImageBase for an image of dimension N will define the Origin, Spacing and direction cosines (DirectionType) in terms on N-vectors. This is incorrect. DICOM scanners routinely produce 2D images set in a 3D world space. 4D image series (3D + time) also exist within a 3D physical space.

In short: the dimension of the physical space is independent of the image dimension. Is there some way to introduce the physical space dimension as a ImageBase template parameter?

The issue was raised and acknowledged on insight-developers recently, c.f. http://www.itk.org/mailman/private/insight-developers/2007-July/009201.html [^]
No tags attached.
Issue History
2007-08-24 22:51Steve RobbinsNew Issue
2007-09-17 08:48Luis IbanezNote Added: 0009012
2007-09-18 01:55Steve RobbinsNote Added: 0009044
2008-01-23 16:03Luis IbanezStatusnew => assigned
2008-01-23 16:03Luis IbanezAssigned To => Luis Ibanez
2008-01-23 16:05Luis IbanezNote Added: 0010259
2008-01-23 16:05Luis IbanezStatusassigned => feedback
2010-10-26 05:57Mathieu MalaterreStatusfeedback => assigned
2010-10-26 05:57Mathieu MalaterreAssigned ToLuis Ibanez => Mathieu Malaterre

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