[Insight-developers] itk::VectorImage

[Brady McCary]

Karthik,

Image< Vector< T, N>, D > will allocate an Image of Vector< T, N > and
each Vector< T, N > will in turn allocate it's N components. Whether
or not there will be fragmentation probably depends on OS's allocation
scheme and the load of the machine at the time of allocation. When you
ask for the pixel at index i, you are (effectively) returned a pointer
to a Vector< T, N >.

VectorImage< T, D > works differently. Instead of explicitly holding
an array of vectors, it holds an array of T. When you ask for a pixel
in a VectorImage it will return to you a VariableLengthVector that has
been initialized to the correct size and the correct offset within the
array of T stored by the VectorImage. The reason why this is possible
is because the array of T held by VectorImage has the following
layout:

1. Let N be the length of the the vectors.
2. Let x_{i,j} represent the jth component of the pixel at index i.
3. Then the layout is:

x_{1,1} x_{1,2} ... x_{1,N} x_{2,1} x_{2,2} ...

So if the user asks for the pixel at index i, the user is returned a
VariableLengthVector whos size is is initialized to N and whos offset
is initialized to i*N. Thus there is no fragmentation. The cost of
this choice that it is difficult/unnatural to make a
VariableLengthVector an lvalue (in the sense of  C++ lvalue), which
effectively makes the forbids the use of
itk::ImageRegionIterator::Value (and relatives).

However, it seems like there is unnecessary complexity in letting the
image change it's dimension at run time, and it does not allow the
compiler to unroll any loops over the components of a
VariableLengthVector.

Brady

On Tue, Apr 14, 2009 at 12:28 PM, Karthik Krishnan
<karthik.krishnan at kitware.com> wrote:
> On Tue, Apr 14, 2009 at 1:14 PM, Brady McCary <brady.mccary+ITK at gmail.com>
> wrote:
>>
>> insight-developers,
>>
>> itk::VectorImage is an image class that has itk::VariableLengthVector
>> as it's pixel type. The reason why these classes were created was for
>> memory layout purposes. For more info, see
>
> Brady:
>
> The intent was to avoid both memory fragmentation, as you point out, and to
> allow for an image whose dimensionality could be changed at run time.
>
> If your length is fixed at compile time and you want to avoid memory
> fragmentation, I think (I have to double check with the developers here)
> that you can use  Image< Vector< T, N >, D >
>
> I believe this would avoid fragmentation and allocate the Vectors as a
> contiguous chunk as opposed to  Image< Array< T >, D >  which would result
> in heavy fragmentation.
>
> --
> karthik
>
>
>>
>> http://www.itk.org/Doxygen/html/classitk_1_1VectorImage.html
>> http://www.itk.org/Doxygen/html/classitk_1_1VariableLengthVector.html
>>
>> The number of components in itk::VariableLengthVector is modifiable at
>> run-time, as opposed to itk::Vector which takes its number of
>> components as a template parameter. Is there a reason why the original
>> developer made the number of components modifiable at run time?
>>
>> Brady
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the ITK FAQ at:
>> http://www.itk.org/Wiki/ITK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.itk.org/mailman/listinfo/insight-developers
>
>
>
> --
> Karthik Krishnan
> R&D Engineer,
> Kitware Inc.
> Ph: 518 881 4919
> Fax: 518 371 4573
>