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
