[vtkusers] vtkImagePermute without copying the data
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.
More information about the vtkusers