Hi Richard,
good to hear that you found a way. I'm inspecting the centerlines,
they look pretty legit to me, so it must be some issue with the merge
script.
Thanks for the data, by the way.
Luca
On Mar 11, 2013, at 11:43 PM, Richard Downe wrote:
> 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 <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
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
------------------------------------------------------------------------------
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
