[Insight-developers] Image::DirectionType should be Nx3 rather than NxN?

[Steve M. Robbins]

On Mon, Sep 17, 2007 at 08:54:28AM -0400, Luis Ibanez wrote:
>
> Hi Steve,
>
> We are following up on the bug report:
>
>   "5573: Image::DirectionType should be Nx3 rather than NxN"
>   http://public.kitware.com/Bug/view.php?id=5573
>
> We are tempted to mark this as a "will not fix" item.
>
> The reason being that when you read a 2D DICOM slice that
> actually has 3D orientation information, such image should
> be read into an ITK image type instantiated for 3D, not an
> image type instantiated for 2D.

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.


> Please let us know if you still consider that this bug
> should be kept open.

I still think it's a bug.

If you need to close it for pragmatic reasons (too hard to fix), I
can't fault you for that.  But it still seems like a wart to me.

-Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.itk.org/mailman/private/insight-developers/attachments/20070918/907e7a34/attachment.pgp