[vtkusers] vtkImagePermute without copying the data

David Gobbi dgobbi at irus.rri.on.ca
Sat Mar 10 21:21:51 EST 2001

On Sun, 11 Mar 2001, John Biddiscombe wrote:

> >If you use 3D textures (VTK doesn't... anyone have some spare time to add
> >them?) then everything can be done in memory, although you have to convert
> Just think what fun you could have redoing all the raycast mappers to 
> permute the axes too!
> ....
> actually, a class like vtkImagePermute which only acted as an access 
> function might just cope. You could have a meta-dataobject which 
> "contained" a real data object and supplied new GetPixel type operations, 
> such that the axes were permuted. This could have a vtkImageData object 
> embedded in it, but not duplicate the memory. It'd be quite interesting 
> because then you could override the Get(index) operations arbitrarily and 
> it'd be a new kind of mapper in a way. (Magnification, scaling, 
> shearing...permuting could all be simulated by changing the indexing scheme 
> into the underlying data - what a pain).

Yeah, it _is_ a pain... take a look inside vtkImageReslice.cxx, that's
basically what it does -- it builds a 4x4 matrix that converts output
(i,j,k) data indices to input (i,j,k) data indices.  That's the
easy part... most of the code in vtkImageReslice deals with interpolation
and special-casing for efficiency.

If it pushed the data through a color map at the same time and then
called glDrawPixels on the result, then it pretty much _would_ be an
all-purpose image mapper.

 - David

More information about the vtkusers mailing list