[Insight-developers] Image as an OrientedImage Progress

Mon Sep 22 12:50:08 EDT 2008

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
>

-- 
--------------------------------------------------------------
Rupert Brooks