[Insight-developers] itk::VectorImage

Wed Apr 15 00:03:48 EDT 2009

Brady:

Yes they are equivalent

For instance a 3D 4 component MetaImage of short pixels can he written/read
in perfectly fine as either.

  Image< Vector< short, 4 >, 3 >
  VectorImage< short, 3 >  (with VectorLength of 4 )

Thanks
--
karthik

2009/4/14 Brady McCary <brady.mccary+ITK at gmail.com<brady.mccary%2BITK at gmail.com>
>

> 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 <brady.mccary%2BITK 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 <brady.mccary%2BITK 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 <brady.mccary%2BITK 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
> >
> >
>
> _______________________________________________
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20090415/7d4b7fab/attachment.htm>