[Insight-developers] VectorImage: and contiguous memory assumption

Tom Vercauteren tom.vercauteren at m4x.org
Thu Mar 24 03:40:27 EDT 2011


Hi Luis,

I most certainly agree that having more control over the memory
organization would be very useful to ITK. I do also think that the
question should not be restricted to vector images. This was actually
one of the points from the ITK v4 wishlist gathered some time ago
(unrelated to NLM-funded ITKv4 and ITKv4 A2D2 contracts):
http://www.itk.org/Wiki/ITK_Release_4/Wish_List#Image_Representation

In my case, what would be the most useful is to be able to specify a
stride that is different from the image width. Having the ability to
specify gaps in between pixels from the same line would also be nice.
With such a representation:
- SSE processing would be made easier
- compatibility with OpenCV and Boost GIL would be simplified
- one could have subsampled image region adaptors (a.k.a. views) on
standard images without any data copy

For the record and inspiration, Boost GIL handles many types on memory
layout in a very elegant manner (but it is restricted to 2D for now):
http://www.boost.org/doc/libs/1_39_0/libs/gil/doc/html/g_i_l_0135.html
http://www.boost.org/doc/libs/1_39_0/libs/gil/doc/html/g_i_l_0152.html

My two cents,
Tom

On Thu, Mar 24, 2011 at 01:49, Luis Ibanez <luis.ibanez at kitware.com> wrote:
> Brad, Nick,
>
> It turned out that I was wrong about the internal
> memory organization of the VectorImage class.
>
> Looking closely at the code, particularly the
> GetPixel, SetPixel methods of this class,
> and after checking with Karthik (who actually
> implemented this class), it turns out that the
> memory organization is actually
>
>
> 1) All the components of pixel 1, followed by
> 2) All the components of pixel 2, followed by
> 3) All the components of pixel 3, followed by
> 4) All the components of pixel 4, followed by
>
> and so on...
>
>
> Instead of what I wrongly thought:
>
>
> 1) All the pixels of component 1, followed by
> 2) All the pixels of component 2, followed by
> 3) All the pixels of component 3, followed by
>
> and so on...
>
>
>
> So, it makes me wonder if there is a case
> to be made for introducing an image class
> with the second type of memory organization...
>
>
>     Luis
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.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