[Insight-developers] Image as an OrientedImage Progress

Luis Ibanez luis.ibanez at kitware.com
Tue Sep 23 10:48:24 EDT 2008 

Hi Rupert,

You bring up a very good point:


What should be the dimension of the type

         ImageType::PointType   ?


The "backward compatible" answer is that it must
have the dimension of the image.

That being said, it will make a lot of sense to
have a new point trait defined with the dimension
of the Space.

         ImageType::SpacePointType  ?

The difficulty here is that we will need to know
that space dimension at compile time. (if we use
the itk::Point<> type for this).

A second option could be to use a plain array
for representing points.... but then... all the
subsequent methods would have to be reimplemented.

Thinking more about this, it seems that the answer
to our problems would be the use of a scene graph
representation for coordinate systems.

More on that in a separate email....


    Luis


---------------------
Rupert Brooks wrote:
> Luis,
> 
> Somewhere else you've made the comment about mental compilation being
> pretty hard, so take my comments with that in mind :-)
> 
> On Mon, Sep 22, 2008 at 12:02 PM, Luis Ibanez <luis.ibanez at kitware.com> wrote:
> 
>>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
> 
> 
> Lets consider the 2D case.  If i have a PNG image, which has no
> inherent direction information, this will load with 2x2 direction
> cosines.  If i have a DICOM slice on the other hand, which has this
> info, it will load with a 2x3 matrix.  If i then declare something of
> type
> 
> ImageType::PointType
> 
> I'm not sure how big it should be.  I suspect its 2 dimensional in the
> first case and three dimensional in the second.  So now i've got
> myself in a bind because that type should be define at compilation
> time.
> 
> I think the real question at the root of this is what does
> TransformIndexToPhysicalPoint return?  I think the dimension of that
> PhysicalPoint has to be defined in the template.
> 
> Would this situation mean that, from an existing 2D image declaration,
> i could end up with world points, and derivative vectors whose sizes
> could not be determined at compile time?   This would cause
> difficulties i think.
> 
> What could work, could be something like
> template<class TPixel, unsigned int VImageDimension = 2, unsigned int
> VSpaceDimension=VImageDimension>
> class itk::Image< TPixel, VImageDimension, VSpaceDimension >
> 
> Sadly, i dont think the default argument for a template parameter can
> be another template parameter, although i didnt try this.  If it
> could, then existing declarations
> 
> itk::Image<float,2>
> 
> would just come up with a 2D in 2D image, which is what is desired, i think.
> 
> 
>>...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.
> 
> 
> Yep - I think my code would probably compile, but it might blow up
> later when one image got loaded as 2D in 2D and the other was 2D in 3D
> and the matrices arent compatible.  On the other hand, i cant
> specifically come up with an example at the moment.
> 
> Rupert
> 
> 
>>
>>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
>>>>
>>>>
>>>
>>>
>>>
>>>
>>_______________________________________________
>>Insight-developers mailing list
>>Insight-developers at itk.org
>>http://www.itk.org/mailman/listinfo/insight-developers
>>
> 
> 
> 
>

More information about the Insight-developers mailing list