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
