[Insight-developers] itk::VectorImage

Tue Apr 14 16:18:29 EDT 2009

Luis,

And allocation continues to be contiguous, even for larger images
(e.g., 512x512x512).

In my particular problem, the data is a contiguous C-array that is in
the same order as VectorImage expects, so for that aspect, it is more
natural to use VectorImage< T, D > with ImportImageFilter than Image<
Vector< T, N>, D > with an Iterator-based copy for the ITK portion of
my computation. The reason why an Iterator-based copy would be
necessary in the latter case is because ImportImageContainer assumes
the pointer you pass to it points to an C-array of a C-type (like
char, float, etc.). Also, the VectorImage technique does not require
storing a pointer for each index of the image, which is of use in my
case because I am dealing with large images. These are the
characteristics of my particular problem.

Is there an implementation of a VectorImage-like class which uses
fixed-length vectors somewhere? If not, I will probably implement it
and share.

Thanks for all of the input, it has helped significantly.

Brady

On Tue, Apr 14, 2009 at 1:47 PM, Brady McCary
<brady.mccary+ITK at gmail.com> wrote:
> 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
>>>
>>
>