The interesting thing I've noticed is that the vessels where I had the "detached outlet" issue segfault, and the ones that meshed correctly don't.
I'll see if I can capture the centerlines of one of these problematic vessels into a .vtp, and post the vtp and the surface stl on dropbox later today. -rd On 03/11/2013 06:36 AM, Luca Antiga wrote: > Hi Richard, > I need to see the data in order to tell you something sensible. > Best, > > Luca > > > On Mar 11, 2013, at 1:48 AM, Richard Downe wrote: > >> So, when I finally teased all the typos out of the source file I sent >> you the other night, I got a single, main vessel centerline with none of >> the branches. >> >> So today, I attempted to sue vmtkbranchextractor. >> >> If I fed the vmtkbranchextractor output directly into >> vmtkcenterlineviewer, things looked more or less as they should (e.g., >> as a tree). >> >> When I tried to pass that result into vmtkmergecenterlines, I get a >> segfault. >> >> Thoughts? >> >> -rd >> >> On 03/08/2013 05:24 AM, Luca Antiga wrote: >>> Hi Richard, >>> >>> On Mar 7, 2013, at 11:42 PM, Richard Downe wrote: >>> >>>> On 03/07/2013 04:26 PM, Luca Antiga wrote: >>>>> 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. >>>> 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. >>> I see now, thanks for the clarification. >>> >>>> 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). >>> You could potentially specify a small absolute -edgelength, but surely >>> making the mesh density adapted to the radius is better. >>> >>>> 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. >>> Not sure I'm giving a sensible suggestion here, but consider using >>> vmtksurfacesubdivision before computing centerlines. Sounds you're >>> experiencing Voronoi degeneracy issues here. >>> >>>> So...I'm not sure how I would use vmtkbranchextractor here, unless I could >>>> feed my initial triangulation into it? >>> Don't confuse vmtkbranchextractor with vmtkbranchclipper. The former just >>> splits centerlines (into branches and assignes GroupIds, TractIds, Blanking >>> and so on) based on the unsplit centerlines, it doesn't need a surface. The >>> latter splits the surface based on the split centerlines. >>> vmtkbranchextractor should work with any set of polylines, as long as >>> they're arranged in a tree-like fashion (not as a network, rather with each >>> line running from the root to an outlet) and as long as a radius array is >>> provided on top of centerlines. >>> >>>> 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. >>> Ok. >>> >>>> 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? >>> Try to see if vmtkbranchextractor (since it only relies on centerlines). >>> Just a suggestion, I don't want to complicate things but you might have not >>> been aware that vmtkbranchextractor is purely centerline-based. >>> >>> >>> Luca >>> >>> >>>> -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 line >>>>>>>>>> Using 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. >>>>>>>>>> Roman >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> This 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 >>>> <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 ------------------------------------------------------------------------------ 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
