Re: [vmtk-users] not all end-points tracked by vmtkcenterlines

[Richard D. <ric...@ui...>]

Attached is a .vtp file for a set of centerlines that crashes 
vmtkcenterlinemerge.  This file is the immediate output of 
vmtkbranchextractor.
-rd

On 03/11/2013 11:32 AM, Richard Downe wrote:
> 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 <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>
>>> ------------------------------------------------------------------------------
>>> 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
>
> ------------------------------------------------------------------------------
> 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