[Insight-developers] itk::VectorImage

Tue Apr 14 14:35:02 EDT 2009

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
>
-------------- next part --------------
CMAKE_MINIMUM_REQUIRED(VERSION 2.6)
IF(COMMAND CMAKE_POLICY)
  CMAKE_POLICY(SET CMP0003 NEW)
ENDIF(COMMAND CMAKE_POLICY)

PROJECT(VectorImage)

FIND_PACKAGE(ITK REQUIRED)
INCLUDE(${ITK_USE_FILE})

ENABLE_TESTING()
INCLUDE(CTest)

ADD_EXECUTABLE(image image.cxx )
TARGET_LINK_LIBRARIES(image ITKCommon)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.cxx
Type: text/x-c++src
Size: 1209 bytes
Desc: not available
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20090414/72ad1b91/attachment.cxx>