[Insight-developers] Image as an OrientedImage Progress

[Luis Ibanez]

Rupert, Kent,


Since the case has been made for both:


   A) Supporting 2D images as native 2D images

and

   B) Supporting 2D images embedded in 3D or higher dimensions


One potential solution could be to add to the itk::Image a "Get"
method that will indicate what is the dimension in which the
image is embedded. (e.g. "unsigned int GetSpaceDimension() const"
or something along those lines).


This is somehow done already in the itk::Mesh, where there is
a distinction between the topological dimension and the mesh
dimension.


In that way, 2D images that are read from Analyze and DICOM files
could declare to be embedded in a 3D space, and therefore have
direction cosines in a 3x2 matrix. (e.g. the axis of the 2D
image are defined by two vectors, each one with 3 components.

In general the dimension cosines matrix will be of size MxN

where

     M = image dimension (itk::Image second template argument)
     N = space dimension (space in which the image is embedded)


Adding the methods will not be too hard.


The Backward Compatibility question arises of what should we
use by default for the dimension of the Direction cosines.


   My 2 cents,


     Luis


--------------------
Rupert Brooks wrote:
> I've used ITK for a lot of image registration tasks, including some
> not exclusively medical ones.  In computer vision and geomatics work,
> 2D images that are really 2D are pretty common.   Genuinely 2D in that
> there is not particularly an implied third dimension.  In this case,
> having a 2x2 set of direction cosines makes perfect sense.    For me,
> conceptually speaking, a 2D slice that is embedded in a 3D volume is
> actually a 3D volume, one voxel thick, and should be read as a 3D
> image.
> 
> I'm definitely not a fan of embedding all 2D images in 3D.  Would all
> image gradients then have to be computed in 3D, although they would be
> meaningless in the direction normal to the image?
> 
> Perhaps a less painful way to fix the issue is, if the image is read
> in 2D, but has 3D direction cosines, the 2D direction cosines are set
> to the identity.  Alternatively, one could project the appropriate set
> of coordinate axes onto the 3D image axes and come up with a set of 2D
> direction cosines related to the original embedding.  Honestly im not
> sure such a projection would actually mean very much.  However, either
> of these approaches would not give degenerate results.
> 
> Cheers,
> 
> Rupert
> 
> 
> On Tue, Sep 16, 2008 at 11:49 AM, kent williams
> <norman-k-williams at uiowa.edu> wrote:
> 
>>There is a similar problem in the Analyze ImageIO, and it's rather baffling
>>that it doesn't show up in e.g. The NIfTI ImageIO.
>>
>>I'm not sure about how to fix this, but the thing about 2D images is that
>>they always have an implied third dimension, which is perpendicular to the
>>acquisition plane.  The ideal situation would be this: if ITK reads a 2D
>>image, it should embed it correctly in a 3D volume. As you point out, that's
>>how DICOM works.
>>
>>I can think of only a couple ways to fix this; one easy and probably wrong
>>in ways that won't matter a large percentage of the time, and one hard and
>>correct.
>>
>>Easy: Stop throwing the exception, and silently allow degenerate dir cosines
>>in 2D.
>>Hard: Make 3 the minimum size for a direction cosine.
>>
>>The 'hard' solution means these things:
>>
>>1. Verify that every ImageIO class fills out 3 vectors even in 2D
>>2. Look for and verify that every class in the library, every example
>>program, and every InsightApplications program, that diddles dir cosines
>>directly does something reasonable in the 2D case.
>>
>>As far as programs by Insight Users go, just going to OrientedImage as the
>>default will break a few of them.
>>
>>On 9/16/08 9:57 AM, "Bill Lorensen" <bill.lorensen at gmail.com> wrote:
>>
>>
>>>Here is the problem with the remaining failing tests. This issue has
>>>been raised before.
>>>See http://public.kitware.com/Bug/view.php?id=5573
>>>
>>>There are really two "dimensions" of an image.
>>>
>>>1) ImageDimension is the number of dimensions in the image container,
>>>1, 2, 3, ...
>>>2) I'll call it SpatialDimension, the number of dimensions in the
>>>coordinate system of the image. This dimension is the dimension used
>>>for origin, spacing and the direction.
>>>
>>>For example, in general, DICOM images have an image dimension of 2,
>>>yet the image position patient and directions are of dimension 3.
>>>Analyze images have the same issue. And I'm sure nrrd's also.
>>>
>>>In the failing tests, single dicom images are selected and the direction
>>>1 0 0
>>>0 0 -1
>>>0 -1 0
>>>
>>>The current logic in ImageFileReader, simply truncates the direction to:
>>>1 0
>>>0 0
>>>which is singular.
>>>
>>>So... we need some further thought about this problem.
>>>
>>
>>
>>
>>Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
>>
>>_______________________________________________
>>Insight-developers mailing list
>>Insight-developers at itk.org
>>http://www.itk.org/mailman/listinfo/insight-developers
>>
> 
> 
> 
>