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

[Elvis Stansvik]

2016-06-28 23:53 GMT+02:00 David Gobbi <david.gobbi at gmail.com>:

> 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, and it makes sense now: The shallow copying of the result and
subsequent discarding of the pipeline must still be done in Python. It's
not enough to just let the pipeline go out of scope, since VTK will then
still hold references keeping the objects of the pipeline alive (preventing
Python garbage collection) (?).


>
>> 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.
>

Yes, makes sense.


>
> 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.
>

Alright.


>
> 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 ;)
>

I'll start small :) Did you mean fun as in challenging and stimulating, or
fun as in I'll tear my hair out?


>
>
>> 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.
>

Bash scripts has their charm as well :) But yes, this is very interesting
work. A lot of the challenges are not in the technical, but in trying to
understand what the user want.

Elvis


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