[Insight-developers] itk::VectorImage

Luis Ibanez luis.ibanez at kitware.com
Tue Apr 14 17:16:16 EDT 2009 

Hi Brady,

Thanks for letting us know about your findings.

I agree that copying the pixel data using image iterators is
probably the safest way to go, but I would have expected
the Import process to work fine as well for an array that
is organized in the same way as an array of Vector<>s.

e.g.  XYZXYZXYZXYZ....

I'm not sure why you are worried about a pointer being used
per index of the image (in the case of the itk::Image of itk::Vector).
The itk::Vector<> class derives from itk::FixedArray<> which is
pretty much equivalent to a C-array. It doesn't have a pointer to
data nor an integer for counting number of elements, as the
itk::Array<> has.


You may want to take a second look at the implementation of
the itk::FixedArray<> class. I'm still under the impression that
it will be a good fit for the use that you describe.


That said, if you find that a new kind of image is needed, then
we will be happy to assist you with the implementation and we
will be even happier to help you submit it as a contribution to
the Insight Journal.


     Regards,


            Luis


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

More information about the Insight-developers mailing list