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
