Memory management.

[Charles Law]

Ron Inbar wrote:

> Thanks, Charles.  This clarifies most issues.  I did try to replace
> vtkExtractVOI and vtkVolume16Reader, but their imaging counterparts seemed
> to give me some trouble, so I switched back.  I'll try again, now that I
> know this should actually give me the behavior I expect.
>
> There's one point I still don't understand, though: why did
> vtkImageGaussianSmooth execute twice, and how did vtkExtractVOI eventually
> get the whole dataset, as requested?  I suppose the output from the two
> executions of vtkImageGaussianSmooth would have to reside in memory
> simultaneously, because that's the only way vtkExtractVOI would have it; but
> then the memory limit would be violated.  And if it's OK for
> vtkImageGaussianSmooth not to obey the memory limit, why does it bother to
> run twice to begin with?  Why not just get it over with in one pass?

MemoryLimit should have really been called SuggestedMemoryLimit.  Filters
that can, try to obey the limit  (sort of like speed limits on highways)...
I have been trying to change filters that actually
try to obey the limit to have a method called SetInputMemoryLimit.

vtkExtractVOI asked for the whole volume.  vtkImageGaussianSmooth tried to
obey the memory limit, and so asked for its input in two pieces
(and executed twice).  The first time vtkVolume16Reader was asked for a piece,
it ignored the request and gave the smooth filter the whole volume.  The
smooth filter does not care if it receives more than it askes for.  When the
reader
was asked for the second piece, it found that it already had the data in its
output,
so it did not have to execute again.

>
>
> I apologize for bothering you with so many questions.  I know the streaming
> stuff is explained in the Developer Guide section of the User's Guide, but I
> found it hard to follow since there were too many details that are only
> relevant for someone actually writing a new class.  I only wanted to
> understand the mechanism.  I hope you understand.

There are issues that even I am unsure of: i.e. what happens if you set the
InputMemoryLimit of the vtkImageClip filter?  It usually copies its input
by reference, so obeying the memory limit would be difficult. I would have
to look at its Update method to see.

>
> Gratefully yours,
>
> Ron
>
> ----- Original Message -----
> From: Charles Law <charles.law at kitware.com>
> To: <rinbar at netvision.net.il>; <vtkusers at gsao.med.ge.com>
> Sent: Friday, October 01, 1999 13:54
> Subject: Memory management.
>
> > Ron,
> >
> > Some filters cannot processes/provide pieces of datasets.
> > Specifically, anything that takes vtkStructuredPoints will request the
> > whole
> > dataset.  So:
> >
> > vtkStructuredPointsWriter Asks for whole ROI  (???MB)
> > vtkExtractROI Asks for WholeDataSet               (128 MB)
> > vtkGaussianSmooth Asks for 50MB, but ....
> > vtkVolume16Reader reads the whole data set.    (128 MB)
> >
> > Now, if you said:
> > reader->GetOutput()->GlobalReleaseDataFlagOn();
> > then filters would release their data when they were finished with it,
> > and you would have memory usage max ~ 256MB.
> >
> > If you use vtkImageReader instead of vtkVolume16Reader,
> > and vtkImageClip instead of vtkExtractROI, then the pipeline
> > could actually process 50MB chunks.
> >
> > But, the structured points writer would still need the whole ROI
> > (size???)
> > before it wrote.  If you used vtkImageWriter, and set the input memory
> > limit
> > to be 50MB,  then truly no filter would process over a 50 MB piece.
> > (Since pipelines are demand driven:   InputMemoryLimit should be set at
> > the
> > end of the pipeline, or on filters whose input is much larger than their
> > output.)
> >
> > In VTK3.0, even the graphics pipeline will support streaming.  However,
> > it may be awhile before a usefully number of sources (ie readers) can
> > supply pieces.
> >
> > Charles.
> >



-----------------------------------------------------------------------------
This is the private VTK discussion list.  Please keep messages on-topic.
Check the FAQ at: <http://www.automatrix.com/cgi-bin/vtkfaq>
To UNSUBSCRIBE, send message body containing "unsubscribe vtkusers" to
<majordomo at gsao.med.ge.com>.  For help, send message body containing
"info vtkusers" to the same address.     Live long and prosper.
-----------------------------------------------------------------------------