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

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

Well, not sure why vmtkmergecenterlines was crashing, but if I pass the 
output of vmtkbranchextractor through vmtkcenterlinesmoothing, and 
simply use that, I get a decent result, and in point of fact, a much 
higher quality mesh than I got simply using target/source seed points 
with vmtkcenterlines, so...I'm probably satisfied.
-rd

On 03/11/2013 01:07 PM, Richard Downe wrote:
> 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
>
>
>
> ------------------------------------------------------------------------------
> 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