<br>We had determined that this subset of the code is where we were having problems, so it&#39;s what we were exercising. Typically we have an Image Viewer attached to the end of the pipeline with a few other modules thrown in..<br>
<br>The dataset is a small subsample of the actual data. The data is to large to fit into memory without either going parallel or streaming, hence the test I provided.<br><br>A typical use case is for a user to read in a particular image, drill into a subregion and trace a feature through the layers above and below (typically around 10 images on either side of the target). They then either make some adjustments or edit some meta-data and then move to another subregion on the same layer, or zoom out, switch layers, and repeat the process.<br>
<br>So, issue number 1 is the data handling piece which is why I was looking at the image streaming/streaming executive. The second issue is that the graphic display of large images is rather pokey at 6k images, and we&#39;ll be moving to tiled 6k images for even higher resolution.<br>
<br>Hope that clarifies what we&#39;re doing and maybe give some insight for a solution.<br><br>Mark<br><br><br><div class="gmail_quote">On Thu, Mar 19, 2009 at 5:43 AM, Kevin H. Hobbs <span dir="ltr">&lt;<a href="mailto:hobbsk@ohiou.edu">hobbsk@ohiou.edu</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">Mark Bolstad wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello list,<br>
<br>
Can someone look at this simple pipeline and explain if I&#39;m using the StreamingPipeline correctly? It&#39;s operating on a set of 6k x 6k images, but any large image set would work. I would expect that the streamer would help reduce the memory usage, but I&#39;m blowing the memory on my mac no matter how I set it,<br>

</blockquote>
<br></div>
I&#39;m very confused by that code, but it looks like you are trying to load a series of images, combine them into a volume, and have the whole thing colorized. Is that correct?<br>
<br>
I can not see any sink (a writer or a renderer) for these data.<br>
<br>
It looks like you are trying to stream the reading of each piece.<br>
<br>
Typically slice readers (like .png and .jpeg) can not read any less than one slice at a time.<br>
<br>
When asked for part of a slice they read the whole thing and throw out the extra.<br>
<br>
I find it&#39;s best to save streaming until the very end so that as much of the pipeline as possible is streamed. If you can use a streamed writer at the end of the pipeline, then it&#39;s possible to avoid EVER loading even one copy of a whole volume.<br>

<br>
The png reader can do the appending of many slices on it&#39;s own all you have to do is give it the file pattern and I think the number of slices.<br>
<br>
Why doesn&#39;t your pipeline look like this?<br>
<br>
   vtkPNGReader -&gt; vtkLookupTable -&gt; vtkImageDataStreamer<br>
<br>
This pipeline could require as little RAM as the final volume plus a few slices.<br>
<br>
If you want to write the colorized volume to disk in say vti format your pipeline could look like this:<br>
<br>
   vtkPNGReader -&gt; vtkLookupTable -&gt; vtkXMLImageDataWriter<br>
<br>
and use as little RAM as one slice plus a few pieces of one slice.<br>
<br>
<br>
</blockquote></div><br>