[vtkusers] Faster slice display

[TJ Wilkinson]

On Mon, 18 Jun 2001, TJ Wilkinson wrote:

> > The image sets I am loading are at largest 1024 square with 360 slices.
> > Simply put, the maximum file size is about 1.3 GB.  The viewer setup I
> > have now seems to read the last 60 or so slices quickly, while the first
> > 300 are slow.  To me, that says that the last 60 slices may be cached in
> > some way.
> 
> A hah.  You should have mentioned this earlier.  Caching the whole volume
> in memory is not an option then.  Disk access is going to be the
> bottleneck, then.  Or even worse, you might be running yourself out of
> physical memory.


I am running NT and looking at system resources while running my program,
I am not close to the physical memory limit of my machine.  I have 1 GB at
my disposal.  Therefore, I would like to pursue the solution you provided
sample code for - the low-res volume.  

I was very happy when I read your solution - it seems to be exactly what I
was looking for.  When I tried it, however, I get a bad_alloc exception
when I try to UpdateWholeExtent.  Since I have enough memory free to load
the downsampled version, I'm thinking that there may be something that I'm
missing in the pipeline that is trying to allocate enough memory for the
entire volume.  If you have any suggestions on how to limit the memory
usage, I am listening carefully.  

> The second thing to try, if the above doesn't speed things up, is
> to use a low-res volume as you said.  You can reduce the resolution as
> follows:
> 
> shrink = vtkImageReslice()
> shrink.SetInput(reader.GetOutput())
> shrink.SetOutputSpacing(x,y,z)  # --- set to 4X the input spacing
> shrink.UpdateWholeExtent()      # --- update & cache low-res volume
> 
> data = shrink.GetOutput()
> data.SetSource(None)  # use NULL if programming in C++
> 
> del shrink     # delete the shrinker  (->Delete from C++)
> del reader     # delete the reader
> 
> Now 'data' has a cache of the low-res volume.  It will still take a
> lot of time to read & shrink the data, but afterwards you will be able to
> slice through it very fast.  Also, in future posts when you refer to
> 'slow' or 'fast' please give an estimate of the frames per second.
> I usually consider anything less than 5 frames/s to be 'slow.'

My slice viewing speed should be at least 3 frames a second at minimum.
The slow I was referring to was around 4 seconds per slice - much slower
than we can use.

Thanks again for your help.

Sincerely,

TJ