[Insight-users] PixelContainers, Iterators,

[Miller, James V (Research)]

I agree traits would be the best way to set the type of pixel container.
This is how it was done originally.

But we ended up only using one pixel container type and the extra trait
class made it difficult to comprehend any syntax errors in your code.
Remember, it is not just a matter of the Image class having an extra
template parameter but that filters are templated over images.  When you
had a compiler error in a filter the error message was so long we had 
difficulty seeing where the error was. The error messages typically show
the full instantiation where the error occurred.  So the compiler says
there was an error in this filter templated over this input image class
which is 
templated over this trait and templated over this output image class
which is template over this trait.... We'd have ten lines out output 
from the compiler before we could see the section of the error message
said "Hey dummy, you left off a semi-colon."

If we decide to introduce a trait for the pixel container type, then 
we should try creating subclasses of image which do not have this trait
template parameter but rather prescribe one on the superclass.  This might
keep the error message size small.





-----Original Message-----
From: John Biddiscombe [mailto:jbiddiscombe at skippingmouse.co.uk]
Sent: Friday, April 30, 2004 4:53 AM
To: Miller, James V (Research); Insight-users at itk.org
Subject: Re: [Insight-users] PixelContainers, Iterators,


Thanks Jim, your reply cheers me up greatly.

> We could probably support other pixel containers via inheritance with

But this would necessitate virtual calls. Using a traits type template for
the pixel container would mean that PixelContainer would be directly
accessible from the class, inlined GetPixel and SetPixel would call
PixelContainer[] operator, and the access could be also inlined and
available directly. using a template would mean that the iterator would have
access to the pixelcontainer operator too and one level of abstraction could
be avoided (no virtual calls needed, yes?)

The iterator would instead of calling GetBufferPointer and storing the
TPixel*, just store a reference to the container and use the [] operator. If
the container were the ImageImportContainer as is the case now, then the
iterator would know the type of the container at compile time, the calls
would be inlined and optimized and existing code would be as efficient, but
replacing the pixelcontainer type with a diskswapping one would be simple.
Am I right?

> 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

Yes please. This is exacly what I wanted to experiment with. only allow [].
yes yes.

> 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

I see. I'll spend a little time looking at the ImageRegionWithIndex and
NeighborhoodIterator if you'd like

thanks

JB

----- Original Message ----- 
From: "Miller, James V (Research)" <millerjv at crd.ge.com>
To: "'John Biddiscombe'" <jbiddiscombe at skippingmouse.co.uk>;
<Insight-users at itk.org>
Sent: Thursday, April 29, 2004 7:53 PM
Subject: RE: [Insight-users] PixelContainers, Iterators,


> 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