[Insight-developers] VectorImage: and contiguous memory assumption

[M Stauffer (V)]

Hi Luis,

How do we access the memory of an Image< Vector, Dimension > object as a
contiguous block?

When I use
Image<Vector,Dimension>::GetPixelContainer::GetBufferPointer(), I get an
array of Vector pointers, not a pointer to a block of pixel elements. 

In a simple test I can get a contiguous block of properly-ordered pixel
elements like this:

Image<Vector<ValueType, VecDim>, Dim>::PixelContainer container =
image->GetPixelContainer();
ValueType* buffer =
reinterpret_cast<ValueType*>(container->GetBufferPointer() );

But is this safe to rely on? That the memory will always be contiguous
and ordered? I take it that itkVector doesn't have any member variables
other than the data, otherwise this wouldn't work.

Thanks.

Cheers,
Michael 

>Hi Brian,
>
>
>The memory layout of the image type
>
>         itk::Image< Vector , Dimension >
>
>for
>
>          Vector = itk::Vector< float, 2 >
>
>is:
>
>      x1 y1 x2 y2 x3 y3 x4 y4.... xN yN
>
>
>Where N is the number of pixels.
>
>
>So,
>the components of a pixel are grouped
>contiguously in memory.
>
>
>      Luis
>
>
>--------------------------
>On Tue, Mar 29, 2011 at 4:09 PM, brian avants <stnava at gmail.com> wrote:
>> luis
>>
>> do you by chance know the memory layout for the
>>
>> itk::Image< Vector , type >  ?
>>
>> is it
>>
>> x1 x2 x3 y1 y2 y3
>>
>> or
>>
>> x1 y1 x2 y2 x3 y3
>>
>> ?
>>
>> brian
>>
>>
>>
>>
>> On Wed, Mar 23, 2011 at 8:49 PM, 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
>>>
>>
>_______________________________________________
>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
>