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
