[vtkusers] vtkImagePermute without copying the data

[David Gobbi]

On Sat, 10 Mar 2001, John Biddiscombe wrote:

> > > Hi there.  Would anybody out there have a class that does the same
> > > thing vtkImagePermute does, but that only changes the attributes
> > > (extents,dimensions,etc.) and references the input data for it's own?
> >
> >This isn't possible.  You can't rearrange the x,y,z of vtkImageData
> >without re-ordering the data in memory.
> 
>  >I'm building a viewer with 3 views for each data set (x,y,z) and the
> 
> The only likely solution would be to redo the mappers (one for each axis) 
> such that they display data in a different order (like copy it to 
> textures). its just about conceivable if you were creating textures in 
> graphics memory and not user memory - then you could get away with one copy 
> of the raw data and N copies of "rendered" stuff.  Not sure I've thought 
> this through properly...hmmm

Yes, it would be possible to have an extra ivar in vtkImageMapper to
specify whether you want to view xy, zx, or yz slices.  Then
vtkImageMapper could do the permutation on-the-fly.  But once this is
added, people might want to add ivars for zoom, pan etc. and it could
all get messy.  Perhaps I should just try to find a way to make 
vtkImageReslice easier to use for this kind of stuff.

Almost all my own imaging pipelines end like this:
  (input)->vtkImageReslice->vtkImageMapToColors->(mapper or texture)
but setting up vtkImageReslice to do the desired permute/clip/pan/zoom
operation can be a pain.  Usually I do the pan/zoom part with textures,
and just use vtkImageReslice for permute/clip (or at times permute/pad).

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
your data to unsigned char ahead of time.  Dynamic window/level on 16-bit
data might be out of the question for 3D textures, if you have to re-load
the whole volume each time.

 - David