[vtkusers] vtk memory issue, support needed

[David Gobbi]

On Mon, Jul 19, 2010 at 5:13 AM, Raúl Ferriz <raul at torresyvalero.com> wrote:
> Hello again!
>
> I'm developing a testing application that should load a DICOM series, and
> display 3 views on 3 render windows (axial, saggittal and coronal). And on a
> fourth render window I want to display a 3D view of the DICOM.
>
> My pipeline is just this:
>
> vtkGDCMImageReader -> vtkChangeInformation --> vtkImageShrink3D ->
> vtkContourFilter -> vtkPolyDataMapper -> vtkActor
>                                           \-> vtkImageViewer2 (to show slice
> axial)
>                                           |-> vtkImageViewer2 (to show slice
> saggittal)
>                                           \-> vtkImageViewer2 (to show slice
> coronal)
>
> All, but vtkImageViewer2 and vtkActor, has ReleaseDataFlagOn to ensure
> little memory footprint.
> My problem is when I try to load a big DICOM series, or when I load an
> unload many DICOM series, seems that memory get fragmentated or something
> like and throws an exception, looking at logs last line is "vtkDoubleArray
> (07FB1DD0): Unable to allocate 67371008 elements of size 8 bytes." I have
> 2gb ram, and also a lot of free swap.
>
>
> On vtkusers forum David Gobby suggested:
> "
> El 15/07/2010 19:15, David Gobbi escribió:
>> The quick answer about VTK splitting memory is that VTK image filters
>> require the image data to be contiguous in memory.  So splitting is
>> not possible.  In summary, large images and Win32 are a bad
>> combination in VTK, due to memory fragmentation and the 2GB limit
>> mentioned by John.
>>
>> Actually, I shouldn't speak in absolutes.  Splitting the volume is
>> possible, but you would have to write a VTK class that would act as a
>> "cache" that contained the volume split into chunks, but that could
>> produce contiguous UpdateExtent-sized slabs for use by its consumers.
>> As long as the downstream filters only requested one slice at a time
>> (or were streamed to only require reasonable-sized blocks) then huge
>> blocks of contiguous memory would never be needed.
>>
>>    David
> "
>
> The fact is that I don't know really know how to implement or use that
> "cache" class and where on the pipeline should be placed. I think that it
> should be placed just after vtkChangeInformation, but I'm not really sure.
>
> If this question only can be answered by "Incident support", please tell me.
>
> Many thanks for your time!

Raul, you should consider whether you can solve your problem by adding
a vtkImageDataStreamer after your vtkImageShrink3D.  If you do all
your rendering from the shrunk image, and never from the full-size
DICOM, then all you need to do is stream the data into the
vtkImageShrink3D so that only the shrunk image is fully stored in
memory (it will be stored in the output of vtkImageDataStreamer, which
will be the branch point to the pipelines for each view).

The "cache class" would only be needed if you wanted to render
full-resolution slices of the image.  If you do all your rendering
after shinking the images, then it would not really be needed.

   David