[vtk-developers] ImagePermute and ImageReslice

[David Gobbi]

On Tue, 18 Jun 2002, Charles Law wrote:

> At 04:05 PM 6/17/2002 -0400, David Gobbi wrote:
> >Hi Charles,
> >
> >You're definitely right that vtkImageReslice makes for an ugly
> >superclass.  Sizewise, vtkImageReslice is pretty nasty.  How about
> >if a base class was broken off from vtkImageReslice that
> >contained just the flip/permute/resample engine?  This would
> >also help to clean up vtkImageReslice a bit.
>
> I don't not know what the best Architecture would be, but this suggestion
> seems better.
> You also mentioned the pad filters.  Would padding have to be in this
> supper class too?

The superclass would support padding (not necessarily at the user API
level) because that chunk of vtkImageReslice code currently supports
padding.  But I'm not yet certain whether it would be worthwhile to
switch the pad filters over.


> >Kind of along the same lines of how to best simplify the imaging
> >pipelin, a huge number of filters simply map a each input voxel
> >through a function to get each output voxel.
> >
> >All of these filters loop over the pixels in exactly the same manner,
> >resulting in a lot of duplicated code (less so now that iterators
> >have been introduced).
> >
> >Why can't these filters simply have a method that will generate a
> >'pixel in -> pixel out' function  e.g.
> >
> >     Func(void *inPtr, void *outPtr)
> >
> >and have all of the looping handled by the superclass?
>
> If this could be done and keep the same performance, it might be nice.

The way that I envision it, there would be 1 object creation overhead per
thread per execution and also one extra function call per image row.  The
overhead would be minimal, about the same as the overhead for iterators.

 - David