[Insight-developers] itk::VectorImage

Tue Apr 14 14:47:51 EDT 2009

Luis,

The output is:

0x6168f0
0x616904
0x616918
5
5

Which would indicate that the allocation is contiguous on my platform:

$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap
--enable-shared --enable-threads=posix --enable-checking=release
--with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada
--enable-java-awt=gtk --disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--disable-libjava-multilib --with-cpu=generic
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC)

Brady

On Tue, Apr 14, 2009 at 1:35 PM, Luis Ibanez <luis.ibanez at kitware.com> wrote:
> Hi Brady,
>
> When building on gcc 4.2, an itk::Image< itk::Vector<T,N>, M >
> allocates all the vector components sequentially.
>
> Please see the attached minimal example that we used for
> verifying this.
>
> As you pointed out, it will be interesting to run it on different
> platforms and under different conditions.
>
> If your main concern is to have a rapid memory access,
> you may find more convenient to use an itk::Image with
> itk::Vectors as pixel types.
>
> It doesn't hurt to run some profiling tests in order to make
> sure that you are choosing the image type that best matches
> the problem that you are trying to address.
>
> The VectorImage was purposely design for applications
> in which the number of components can't be known at
> compilation time. In particular: Image classification problems,
> and analysis of DTI images.
>
>
> Please let us know what you find when running this
> attached code in your platform.
>
>
>       Thanks
>
>
>             Luis
>
>
> --------------------------------------------------------------
> On Tue, Apr 14, 2009 at 1:58 PM, Brady McCary
> <brady.mccary+ITK at gmail.com> wrote:
>> 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
>>>
>> _______________________________________________
>> 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
>>
>