[Insight-developers] Image as an OrientedImage Progress

[Luis Ibanez]

Let's then elaborate down the path of Steve's suggestion.

For example:

One option could be to replace the declaration of the DirectionType
type from


    typedef Matrix<double,
       VImageDimension, VImageDimension> DirectionType;

to

     typedef vnl_matrix<double>     DirectionType;


Most of the matrix-like operations should still work, and we will
have the flexibility of allocating the size of this matrix to be


     2D image embedded in 2D -----> matrix of 2x2
     2D image embedded in 3D -----> matrix of 3x2
     3D image embedded in 3D -----> matrix of 3x3
     3D image embedded in 4D -----> matrix of 4x3

...and so on...

Presumably, users should have used the type via the traits of
the image, as opposed to constructing the matrix type from
scratch, and therefore most of their code your compile.


Rupert,

   do you see this option breaking backward compatibility ?



     Luis


--------------------
Rupert Brooks wrote:
> Steve, Luis, Kent,
> 
> One reason this suggestion stirred me out of my usual inertness is
> that i could see it breaking a heck of a lot of code of mine.  In
> short, it scared me :-)
> 
> As Luis pointed out, theres an issue of backwards compatibility, and
> thats what my concern amounts to.
> 
> Sadly, i dont have a great solution to this issue.  If i have 2D
> images that have three direction cosines, i treat them as a volume one
> voxel thick.
> 
> I like Steves suggestion - the current status quo becomes the case
> when spatial dimension==image dimension.  This addresses the issue of
> backwards compatibility nicely, while allowing images embedded in a
> higher dimension for those whose applications require it.
> 
> Rupert
> 
> On Mon, Sep 22, 2008 at 11:39 AM, Steve M. Robbins <steve at sumost.ca> wrote:
> 
>>On Mon, Sep 22, 2008 at 08:53:27AM -0400, 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.
>>
>>Neither am I.  Fortunately, I don't think that is being proposed.
>>
>>The status quo, where all 2D images are embedded in a 2D space
>>regardless of what the image format says, is equally bad.
>>
>>The crux of the matter is, as Bill said in the beginning, is there are
>>really two dimensions to an image.
>>
>>
>>>>On 9/16/08 9:57 AM, "Bill Lorensen" <bill.lorensen at gmail.com> wrote:
>>>>
>>>>
>>>>>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.
>>
>>Is it possible that the Image class could simply acquire a new
>>template parameter for SpatialDimension?  But then there are 4D
>>coordinate systems where one dimension is time; you might have a
>>2D or 3D slice out of a 4D space and desire the origin and direction
>>cosines to use the 3D spatial coordinates.
>>
>>So maybe some kind of helper class for coordinates is the way to go,
>>akin to the image container class?  The helper class would know the
>>structure of the embedding space and be able to return sensible point
>>and vector classes suitable for, e.g., the origin and the direction
>>cosines.
>>
>>-Steve
>>
>>
>>-----BEGIN PGP SIGNATURE-----
>>Version: GnuPG v1.4.9 (GNU/Linux)
>>
>>iD8DBQFI17wV0i2bPSHbMcURAsVTAJoD2v9fKPoc7kzEQVg9TKiwrEPDrACeOdZj
>>9I2+qytHLabLqNfx8Mxkk3I=
>>=kZa7
>>-----END PGP SIGNATURE-----
>>
>>_______________________________________________
>>Insight-developers mailing list
>>Insight-developers at itk.org
>>http://www.itk.org/mailman/listinfo/insight-developers
>>
>>
> 
> 
> 
>