Re: [vmtk-users] not all end-points tracked by vmtkcenterlines
Brought to you by:
davidsteinman,
lucantiga
Menu
▾
▴
Re: [vmtk-users] not all end-points tracked by vmtkcenterlines
|
From: Richard D. <ric...@ui...> - 2013-03-11 00:48:34
|
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 <ric...@ui...> 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 >>>>>>>>>> vmt...@li... >>>>>>>>>> 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 >>>>>>> vmt...@li... >>>>>>> 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 >>>> vmt...@li... >>>> https://lists.sourceforge.net/lists/listinfo/vmtk-users >> <centerlines.png> |
