[vtkusers] "Disabling" a volume rendering pipeline in a controlled way?

[David Gobbi]

On Tue, Jun 28, 2016 at 2:29 PM, Elvis Stansvik <
elvis.stansvik at orexplore.com> wrote:
>
>
> That's interesting. So if I understand the above correctly, you create a
> little ad-hoc pipeline for the purpose of reading the file, and then keep
> only what you need.
>

Yes, exactly.  The ad-hoc pipeline is sometimes more than just a reader, it
might also massage the image by changing the orientation or the data type.


> In my case I'm working from Python, though for various reasons I'm at
> least entertaining the idea of re-writing what I have in C++. But say I
> stick to Python, would the shallow copying maneuver above be relevant in
> Python-land?
>

It'll work exactly the same in Python as C++.


> I see. In my case I'm not going to have any pure-processing pipelines.
> Most of what I'll use VTK for is interactive visualization, where I may
> want to tweak certain aspects of the visualization while it is shown
> (transfer functions, volume of interest extraction bounds, transforms,
> ...). So I think I want to keep the entire pipeline alive in most cases
> (but see my question further down), even if some nodes in the pipeline can
> be "hidden" in the sense that I don't need to keep around references to
> them. The nodes I do have to keep references to are of course the ones
> where I'll need to tweak things.
>

This sort of interactive display pipeline is what VTK was made for.


> Ah, perhaps it would make sense for me to also break out the pipeline
> construction/destruction logic out of my widget into a separate class, even
> if I don't have destructors in the C++ sense.
>

Since the "clean-up" that you want to do is mainly just deleting all the
object you don't need anymore, it should be fine if all your VTK filter
objects are members of your break-out class.  You have to rely on the
Python & VTK reference counting to take care of the destruction.

The fact that C++ provides so many options for how to do memory management
is a nice feature (or maybe the lack of unified memory management is a
non-feature?)

Interactive processing pipelines (as opposed to the run-once pipelines) are
>> temporarily connected to a display pipeline via the usual
>> AddInputConnection() mechanism, but when the interaction is complete the
>> following is done: 1) the connection is broken with e.g.
>> RemoveAllInputConnections(), 2) the output is shallow-copied into a new
>> data object with the CopyStructure()/PassData() calls and the processing
>> pipeline is deleted, and 3) the copy is connected directly to the display
>> pipeline (and generally stored in my data management structure, as well).
>>
>
> Hm, now I think I understand what you mean. So you have a general
> "processing" segment of the pipeline, and a visualization pipeline that
> follows, and you keep the processing part of it alive only for as long as
> you need it.
>
> I then just have one question I think: What if you later need to "hook up"
> the processing segment again? Do you discard the shallow copy you made,
> create a new processing pipeline segment and hook it up to the
> visualization segment?
>

Yes, the pipeline segment is re-created.  Its input is set (via
SetInputData) to the vtkImageData object that came from the reader (or to
some other vtkImageData object) and then this pipeline segment is connected
to the display pipeline.  The previous input to the display pipeline can be
thrown away or placed on an undo stack.

The general idea is that pipeline segments only exist for as long as they
>> are being used, i.e. they are either limited to the scope of a single
>> function, or limited to the lifetime of a specific object. This helps to
>> reduce the overall resource usage of the application.
>>
>
> I like this design, and it makes sense. I'll have to think about it some
> more.
>
> A little about my use case: It's a tool for looking at tomographic images
> of drilled rock cores, along with some spectral analysis results (plots).
> The user will be able to see a scale showing drilled depth (~1000 m), with
> some segments indicating where there are samples available. Clicking such a
> segment (~1 m) will bring up the volume corresponding to that sample in a
> VTK view. If the user wishes to go even closer, he/she should be able to
> select a smaller (~10 cm) segment in the ~1 m view, which will bring that
> segment up in a third (larger) view which has free zooming/rotation. And
> another thing is that the user must be able to adjust the color/opacity
> transfer functions used in the volume rendering. Not everything is ironed
> out yet, but that's the gist of it, as far as VTK is involved.
>

Sounds interesting.  The "selection" part will be fun ;)


> Again, thanks a lot for your input, you've been very helpful.
>

You're making me jealous, because lately I've been dedicating most of my
time to writing command-line image processing scripts with bash (not
fun!).  But next month I'll be getting back into app development.

 - David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160628/2792a6e7/attachment.html>