On 03/07/2013 04:26 PM, Luca Antiga wrote:
I mean that the branches and vessel are segmented separately in different tools, and then projected into 3-d space using a variation on Frenet-Serret analysis. I build a triangulated surface using CGAL from this point set, and using a python module I wrote myself, slurp this, along with the centerlines of the individual surfaces, into vmtk.On Mar 7, 2013, at 9:44 PM, Richard Downe wrote:Well...I'm not using vmtkbranchextractor. My branches and vessel are defined separately, and I merge them in a pre-vmtk process. I have centerlines a priori, but it is not a unified centerline tree. (I have until now been using source and target points. This works well in most vessels, but heavily branched ones frequently drop a branch, often the largest one, during the run of vmtkcenterlines, so after reading this thread, I concluded I wasn't alone, and set about trying to reengineer it.)I'm not sure I fully understand. A screenshot would help.
The reason for this is that I work with coronary ultrasound. The segmentation of both the vessel and the branches are each less straightforward than they are for, say, pulmonary CT.
vmtkmeshgenerator failed outright until I began using vmtkcenterlines to help it calibrate the triangle and tetrahedral density. (The ultimate goal is CFD analysis using Ansys Fluent).
In some heavily branched vessels, the outflow surface of one the branches shows up as unconnected to the rest of the mesh when I load it into fluent. These are also generally vessels where vmtkcenterlines has convergence issues.
So...I'm not sure how I would use vmtkbranchextractor here, unless I could feed my initial triangulation into it? As such, I'm attempting what I realize is something of a hack, feeding centerlines and radius information that I have a priori into vtkvmtkMergeCenterlines in an attempt to get a proper vessel tree without having to rely upon vmtkcenterlines' procedure.
I don't have the "blanking regions" stored anywhere, because it's not part of the workflow that leads up to this, but would be fairly trivial to surmise, as I could simply test each branch centerline point to see if it lies closer than vesselRadius[i] to vesselCenterline[i], for all i.
Thus, my centerline *is* already broken into branches, but not using vmtkbranchextractor. Attached is a screenshot of the result of running it with what were clearly mistaken group/tract ids. It clearly tried to connect all segments, but with no knowledge of where bifurcations were, simply tacked them all end-to-end to form 1 centerline.
So really...I'm trying to figure out, if I must synthesize group and tract ids, how do I do so in a way that will correctly inform the merging of my branch centerline segments?
-rd
I just tried running it with groupID==centerlineID for all centerlines, and tractID = uniformly 1, and blanking = uniformly 0. The result was an unruly knot that suggested that it didn't know what to connect to what.Yes, the centerline has to be first split into branches using vmtkbranchextractor (which will identify bifurcations, split and group) and then vmtkcenterlinemerge will generate one centerline per group and create a proper network.I suspect, after digging through the vtkVmtk source code and looking at this http://www.vmtk.org/Tutorials/BranchSplitting/ example, I need to actually annotate the bifurcation regions by setting group and tract id, and blanking, correctly.Yes, but you also need to split centerline cells in chunks, as depicted in the branch splitting tutorial.If I understand this correctly, I can create a bifurcation region by identifying where the branch departs the vessel, and appending 1 location on the vessel centerline to the branch centerline at the proximal-most location. And then, groupID increments at and after each bifurcation region, and blanking is set to 1 in each bifurcation region. I'm less clear on tract ID. Is it always either 1 or 2, depending whether before or after the bifurcation point? Or does it get set to a unique value for each chunk vis a vis group id?Consider the individual centerline cell originally running between inlet and outlet. Now that you have split it in chunks, number each chunk from 0 to n. That's the tract id.I won't be able to get to it until this evening, but I believe that's the next logical step.Keep us posted. However, I'd also like to understand more of your approach, so if you could clarify your first paragraph that would be great. Thanks Luca-rd On 03/07/2013 10:35 AM, Luca Antiga wrote:Hi Richard, just pipe vmtkcenterlinemerge after vmtkbranchextractor and use -ofile to write the file out, that's the quickest. What is your exact issue? Roman: I haven't got an answer for you yet - I've been taking care of the quick messages but yours requires a free slot of time. Thanks for your patience. Luca On 06/mar/2013, at 18:31, Richard Downe <richard-do...@uiowa.edu> wrote:Luca-- I've been vexed by a similar situation for awhile that I'm just now getting around to tackling. One thing I *do* have, however, is centerlines for my main vessel an all branches. I've noticed a vmtkcenterlinemerge.py/vtkvmtkMergeCenterlines.h/cxx that don't appear to be used anywhere, so I can't find a usage example. What do I need to pass in for the tract ids and blanking ids to make this work, or do you have a usage example somewhere? -rd On 03/04/2013 07:00 AM, Luca Antiga wrote:Hi Roman, I'll really need to take a closer look to the data you sent, I'm planning to do it in the next few days. Thanks Luca On Mar 4, 2013, at 1:54 PM, Dr. Roman Grothausmann wrote:On 23/02/13 13:56, Luca Antiga wrote:Possible workarounds: 1. Try to use Tetgen to generate the internal Delaunay tessellation, instead of the default algorithm. This can be easily done by specifying -usetetgen 1 in the vmtkcenterlines command lineUsing tetgen I get an error and the resulting VTP-file is empty (second workaround is still running): Reading VTK XML surface file. Executing vmtkcenterlines ... Cleaning surface. Triangulating surface. Computing centerlines. Computing centerlines...Running TetGen. TetGen command line options: pT1.000000e-08dzQ ERROR: In /home/grr/programme/vmtk-1.0.1/vtkVmtk/ComputationalGeometry/vtkvmtkNonManifoldFastMarching.cxx, line 667 vtkvmtkNonManifoldFastMarching (0xe6fdac0): Cost function array with name specified does not exist! ERROR: In /home/grr/programme/vmtk-1.0.1/vtkVmtk/ComputationalGeometry/vtkvmtkSteepestDescentLineTracer.cxx, line 318 vtkvmtkSteepestDescentLineTracer (0xe6f9210): Descent array with name specified does not exist! Done executing vmtkcenterlines. Writing VTK XML surface file. Output vmtkcenterlines members:2. Compute the Delaunay tessellation on the closed surface (prior to cutting the endcaps open) using vmtkdelaunayvoronoi and feed it to vmtkcenterlines, this way: vmtkdelaunayvoronoi -ifile unclipped.vtp --pipe vmtkcenterlines -ifile clipped.vtp ...Using this command causes no errors but the resulting file is also empty. Any ideas what else I could try? Many thanks for any help or hints. RomanThis will allow you to take advantage of the clipped endcaps for the seedselector (since you feed clipped.vtp as input to vmtkcenterlines) but use the Delaunay tessellation computed from the unclipped one, which shouldn't have the issue with the artifactual inner tets. In any case, it would be good for me to have the surface so I can use it to fix the internal delaunay tet selection issue. Best, Luca On Feb 22, 2013, at 9:32 AM, Dr. Roman Grothausmann wrote:(now with images) Dear mailing list members, Another problem I have is that not all end-points that I extract from the output of vmtknetwork (magenta lines in attached image) are tracked by vmtkcenterlines (grey/blue lines), most are but some are not. See the end points of the magenta lines of which a grey line stretches like a cobweb string. After removing these cobweb lines I end up with the blue lines which are OK except for the lacking branches. What could be the reason for that and how could I avoid it? Any help or hints are very much appreciated Roman -- Dr. Roman Grothausmann Tomographie und Digitale Bildverarbeitung Tomography and Digital Image Analysis Institut für Funktionelle und Angewandte Anatomie, OE 4120 Medizinische Hochschule Hannover Carl-Neuberg-Str. 1 D-30625 Hannover Tel. +49 511 532-9574 <KO4_01_08_12_002_PD PMT_seg-8bit_fh0_obs_d1 orig_fh0_obs_mc50_lmp_nw-skel1.05_ep_s2t0_mo004_ep_cl_01_03.gif><KO4_01_08_12_002_PD PMT_seg-8bit_fh0_obs_d1 orig_fh0_obs_mc50_lmp_nw-skel1.05_ep_s2t0_mo004_ep_cl_01_05.gif>------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb_______________________________________________ vmtk-users mailing list vmtk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/vmtk-users-- Dr. Roman Grothausmann Tomographie und Digitale Bildverarbeitung Tomography and Digital Image Analysis Institut für Funktionelle und Angewandte Anatomie, OE 4120 Medizinische Hochschule Hannover Carl-Neuberg-Str. 1 D-30625 Hannover Tel. +49 511 532-9574------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ vmtk-users mailing list vmtk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/vmtk-users------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ vmtk-users mailing list vmtk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/vmtk-users
<<attachment: centerlines.png>>
------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________ vmtk-users mailing list vmtk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/vmtk-users
