[Insight-users] PixelContainers, Iterators,

[Miller, James V (Research)]

This technology was lost in the process of reducing template parameters. :(

At one time, the image class was templated over the type of pixel
container and we supported two types of pixel containers.  But in the
end, all anyone ever used was one type of pixel container so we 
simplified the design.

We could probably support other pixel containers via inheritance with 
only minor restructuring.  

I had a design which would allow "disk" pixel containers.  It only required
a few changes to how people used pixel containers.  The idea was that the 
access to a pixel container would be limited to operator[].  All iterators
would communicate with the pixel container using a linear offset passed to
operator[]. So, as far as the image class and iterator classes were
concerned, 
an image looked like a continuous block of memory.  However, the pixel
container
would have the freedom storing the data in any manner it wanted, for
instance, 
each slice could be a continuous block of memory but the slices could be 
disjoint. This could really help us in some large data problems.

We would have to rewrite the iterators to not call GetBufferPointer(). This
wouldn't
be too hard for ImageRegionIterator since it only modifies an offset as it
moves.
ImageRegionWithIndex and NeighborhoodIterator would be harder to work with.
I do 
regret writing GetBufferPointer().  By the time I realized it was a mistake,

it was being used too much to remove simply.  But at the time, I was more 
worried about the iterator API and N-dimensional transversal than the impact
of GetBufferPointer().

Of course, we have to determine whether there is any impact to performance
by not using GetPixelBuffer().

Jim




-----Original Message-----
From: John Biddiscombe [mailto:jbiddiscombe at skippingmouse.co.uk]
Sent: Thursday, April 29, 2004 11:48 AM
To: Insight-users at itk.org
Subject: [Insight-users] PixelContainers, Iterators,


itk::Image has PixelContainer type set to

typedef ImportImageContainer<unsigned long, PixelType> PixelContainer;

Which would imply that I can't use a different storage method for pixels.
Are there not traits which I can manipulate to change the pixel container?
The reason is that to manage memory I'd like to experiment with a virtual
pixel memory manager which would swap chunks in and out of memory. Replacing
the pixel container with a custom container which supplied the required []
type operators would be a nice way of implementing this. Code would not be
allowed to request GetBufferPointer, which would not necessarily return
anything meaningful.

itkConstImageIterator accesses memory by fetching the BufferPointer
TPixel *GetBufferPointer() and then traversing linearly...
"ImageConstIterator assumes a particular layout of the image data. In
particular, the data is arranged in a 1D array as if it were
[][][][slice][row][col] with Index[0] = col, Index[1] = row, Index[2] =
slice, etc."

Is there no straightformward way of replacing the pixelcontainer, and
modifying the basic iterators such that they query the pixelcontainer,
rather than accessing memory directly? (I realize that there's a buffered
region which handles this type of scenario, but the problem with this
mechanism is that I'd like the whole image to "appear" as if it was in
memory even though in fact it isn't. I can't see an easy way of manipulating
the buffered region to achieve this).

thanks

JB

_______________________________________________
Insight-users mailing list
Insight-users at itk.org
http://www.itk.org/mailman/listinfo/insight-users