[Insight-developers] itk::VectorImage

[Karthik Krishnan]

Brady:

I have to double check with Brad King on that, but I believe that the class
Vector and FixedArray may get stored continguously in memory at least with
gcc, with the compiler knowing fully well the size the elements being held
by the class. Not sure though. Have to check with minimal code.

With VectorImage, by design, it provides a facade to a VariableLengthVector
pixel type (internally it just holds T * N elements in contiguous memory)
and hence does, as you mention, avoid fragmentation.

One of the requirements when I wrote the VectorImage class was to support
multi-component images, for instance multi-band (hyperspectral) images,
where the number of bands cannot be known at compile time. Its was a feature
at the time the class was written, not an unnecessary complexity.

--
karthik

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
> >
>



-- 
Karthik Krishnan
R&D Engineer,
Kitware Inc.
Ph: 518 881 4919
Fax: 518 371 4573
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20090414/b457f9e5/attachment.htm>