<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-06-28 23:53 GMT+02:00 David Gobbi <span dir="ltr"><<a href="mailto:david.gobbi@gmail.com" target="_blank">david.gobbi@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Tue, Jun 28, 2016 at 2:29 PM, Elvis Stansvik <span dir="ltr"><<a href="mailto:elvis.stansvik@orexplore.com" target="_blank">elvis.stansvik@orexplore.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><span><div><br></div></span><div>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.<br></div></div></div></div></div></blockquote><div><br></div></span><div>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.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div>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?<br></div></div></div></div></div></blockquote><div><br></div></span><div>It'll work exactly the same in Python as C++.</div></div></div></div></blockquote><div><br></div><div>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) (?).<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.<br></div></div></div></div></blockquote><div><br></div></span><div>This sort of interactive display pipeline is what VTK was made for.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.<br></div></div></div></div></blockquote><div><br></div></span><div>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.</div></div></div></div></blockquote><div><br></div><div>Yes, makes sense.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>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?)</div></div></div></div></blockquote><div><br>:)<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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).</div></div></div></div></blockquote><div><br></div></span><div>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.<br><br></div><div>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?<br></div></div></div></div></blockquote><div><br></div></span><div>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.</div></div></div></div></blockquote><div><br></div><div>Alright.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div></div></div></div></blockquote><div><br></div></span><div>I like this design, and it makes sense. I'll have to think about it some more.<br><br></div><div>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.<br></div></div></div></div></blockquote><div><br></div></span><div>Sounds interesting.  The "selection" part will be fun ;)</div></div></div></div></blockquote><div><br></div><div>I'll start small :) Did you mean fun as in challenging and stimulating, or fun as in I'll tear my hair out?<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>Again, thanks a lot for your input, you've been very helpful.<br></div></div></div></div></blockquote><div><br></div></span><div>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.</div></div></div></div></blockquote><div><br></div><div>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.<br><br></div><div>Elvis<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="HOEnZb"><font color="#888888"><div><br></div><div> - David</div></font></span></div><br></div></div>
</blockquote></div><br></div></div>