[Insight-developers] itk::VectorImage

Tue Apr 14 18:04:50 EDT 2009

Brad,

I wrote a test case and, to my surprise, the buffer pointers of an
itk::Image<Vector> and an itk::VectorImage are the same. I created the
test case from the test case Luis sent a few hours ago, and all 3
files are attached.

This is a nice, thanks guys for clearing all of this up.

Brady

On Tue, Apr 14, 2009 at 4:20 PM, Bradley Lowekamp
<blowekamp at mail.nih.gov> wrote:
> Actually I don't think an Image<Vector<T,N>,D> will store an extra pointer
> per pixel. itk::Vector is derived from itk::FixedArray. And FixedArray
> is similar to
> class CArray {
> unsigned char data[N];
> }
> C++ is smart enough to know it doesn't need an extra pointer here. Also
> std::cout << sizeof(itk::Vector<char, 10> ) << std::endl;
> Gives me:
> 10
> as output.
> Brad
> On Apr 14, 2009, at 4:18 PM, Brady McCary 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
>
>
>
> _______________________________________________
> 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
>
> ========================================================
>
> Bradley Lowekamp
>
> Lockheed Martin Contractor for
>
> Office of High Performance Computing and Communications
>
> National Library of Medicine
>
> blowekamp at mail.nih.gov
>
>
-------------- 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)

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