vmtk-users

[vmtk-users] centerlines question

[Joong-Ho W. <jh...@st...>]

Hi,

I compiled and installed vmtk0.6 on a Windows XP machine. It seems work 
fine, but I have a trouble with using vmtkcenterlines.

I want to extract centerlines of the abdominal aorta and its branches. 
As a simple test, I segmented the aorta (below the heart and above the 
iliac bifurcation) and the right renal artery from a CTA data, resulting 
in a T-shaped branching. Then I obtained a surface model using 
vmtkmarchingcubes (I basically followed the tutorial in the website).

Next, I ran vmtkcenterlines:

vmtkcenterlines.py -ifile p001_part1_model.vtp -ofile 
p001_part1_centerlines2.vtp

as in the tutorial.

As I wanted T-shaped centerlines, I thought that I need two pairs of 
source and target points. I chose both source points to be the same: the 
proximal endpoint of the aorta. Target points are chosen to be the 
distal end of the aorta and the end of the renal artery.

Since the model is a closed surface, I pressed space *twice* on the top 
of the aorta surface to select the source points. For target points I 
pressed space on two different points on the surface, of course.

During centerline extraction, a vtkOutputWindow popped up and complained :

Unable to factor linear system

which was a vmtkMath error.

When I displayed the centerlines (p001_part1_centerlines2.vtp, using 
vmtkcenterlineviewer), I only see a single centerline, which I guess is 
one for the aorta.

I tried again with only a single source point, but the result was the same.

Interestingly, the Voronoi diagram looked fine.

To summarize,

1. I can't see multiple centerlines.
2. I have no confidence on my selection of source and target points 
(what is the precise definition of these points?)

It appears that I made some simple mistake, but can't guess what it is.
FYI, I attach the output of vmtkcenterlines below. It seems that the 
script produces only one centerline.

Thanks in advance,

Joong-Ho.



C:\Program Files\VMTK\bin>vmtkcenterlines.py -ifile p001_part1_model.vtp -of
p001_part1_centerlines2.vtp

Creating vmtkCenterlines instance.
Automatic piping vmtkcenterlines
Parsing options vmtkcenterlines
     SurfaceInputFileName = p001_part1_model.vtp
     CenterlinesOutputFileName = p001_part1_centerlines2.vtp
Explicit piping vmtkcenterlines
Input vmtkcenterlines members:
     Id = 0
     Surface = None
     SurfaceInputFileName = p001_part1_model.vtp
     SeedSelectorName = pickpoint
     SourceIds = []
     TargetIds = []
     SourcePoints = []
     TargetPoints = []
     AppendEndPoints = 0
     FlipNormals = 0
     CapDisplacement = 0.1
     RadiusArrayName = MaximumInscribedSphereRadius
     AppendEndPoints = 0
     Resampling = 0
     ResamplingStepLength = 1.0
     DelaunayTessellation = None
     UseTetGen = 0
     TetGenDetectInter = 1
     CostFunction = 1/R
     CenterlinesOutputFileName = p001_part1_centerlines2.vtp
     DelaunayTessellationOutputFileName =
     VoronoiDiagramOutputFileName =
Reading VTK XML surface file.
Executing vmtkcenterlines ...
NonManifold check.
Cleaning surface.
Triangulating surface.
Capping surface.
Please position the mouse and press space to add source points, 'u' to undo
Please position the mouse and press space to add target points, 'u' to undo
Computing centerlines.
Done executing vmtkcenterlines.
Writing VTK XML surface file.
Output vmtkcenterlines members:
     Id = 0
     Centerlines = vtkPolyData
     RadiusArrayName = MaximumInscribedSphereRadius
     EikonalSolutionArrayName = EikonalSolutionArray
     EdgeArrayName = EdgeArray
     EdgePCoordArrayName = EdgePCoordArray
     CostFunctionArrayName = CostFunctionArray
     DelaunayTessellation = vtkUnstructuredGrid
     VoronoiDiagram = vtkPolyData
     PoleIds = vtkIdList

[vmtk-users] centerlines question

[Joong-Ho W. <jh...@st...>]

Hi,

I compiled and installed vmtk0.6 on a Windows XP machine. It seems work 
fine, but I have a trouble with using vmtkcenterlines.

I want to extract centerlines of the abdominal aorta and its branches. 
As a simple test, I segmented the aorta (below the heart and above the 
iliac bifurcation) and the right renal artery from a CTA data, resulting 
in a T-shaped branching. Then I obtained a surface model using 
vmtkmarchingcubes (I basically followed the tutorial in the website).

Next, I ran vmtkcenterlines:

vmtkcenterlines.py -ifile p001_part1_model.vtp -ofile 
p001_part1_centerlines2.vtp

as in the tutorial.

As I wanted T-shaped centerlines, I thought that I need two pairs of 
source and target points. I chose both source points to be the same: the 
proximal endpoint of the aorta. Target points are chosen to be the 
distal end of the aorta and the end of the renal artery.

Since the model is a closed surface, I pressed space *twice* on the top 
of the aorta surface to select the source points. For target points I 
pressed space on two different points on the surface, of course.

During centerline extraction, a vtkOutputWindow popped up and complained :

Unable to factor linear system

which was a vmtkMath error.

When I displayed the centerlines (p001_part1_centerlines2.vtp, using 
vmtkcenterlineviewer), I only see a single centerline, which I guess is 
one for the aorta.

I tried again with only a single source point, but the result was the same.

Interestingly, the Voronoi diagram looked fine.

To summarize,

1. I can't see multiple centerlines.
2. I have no confidence on my selection of source and target points 
(what is the precise definition of these points?)

It appears that I made some simple mistake, but can't guess what it is.
FYI, I attach the output of vmtkcenterlines below. It seems that the 
script produces only one centerline.

Thanks in advance,

Joong-Ho.



C:\Program Files\VMTK\bin>vmtkcenterlines.py -ifile p001_part1_model.vtp -of
p001_part1_centerlines2.vtp

Creating vmtkCenterlines instance.
Automatic piping vmtkcenterlines
Parsing options vmtkcenterlines
     SurfaceInputFileName = p001_part1_model.vtp
     CenterlinesOutputFileName = p001_part1_centerlines2.vtp
Explicit piping vmtkcenterlines
Input vmtkcenterlines members:
     Id = 0
     Surface = None
     SurfaceInputFileName = p001_part1_model.vtp
     SeedSelectorName = pickpoint
     SourceIds = []
     TargetIds = []
     SourcePoints = []
     TargetPoints = []
     AppendEndPoints = 0
     FlipNormals = 0
     CapDisplacement = 0.1
     RadiusArrayName = MaximumInscribedSphereRadius
     AppendEndPoints = 0
     Resampling = 0
     ResamplingStepLength = 1.0
     DelaunayTessellation = None
     UseTetGen = 0
     TetGenDetectInter = 1
     CostFunction = 1/R
     CenterlinesOutputFileName = p001_part1_centerlines2.vtp
     DelaunayTessellationOutputFileName =
     VoronoiDiagramOutputFileName =
Reading VTK XML surface file.
Executing vmtkcenterlines ...
NonManifold check.
Cleaning surface.
Triangulating surface.
Capping surface.
Please position the mouse and press space to add source points, 'u' to undo
Please position the mouse and press space to add target points, 'u' to undo
Computing centerlines.
Done executing vmtkcenterlines.
Writing VTK XML surface file.
Output vmtkcenterlines members:
     Id = 0
     Centerlines = vtkPolyData
     RadiusArrayName = MaximumInscribedSphereRadius
     EikonalSolutionArrayName = EikonalSolutionArray
     EdgeArrayName = EdgeArray
     EdgePCoordArrayName = EdgePCoordArray
     CostFunctionArrayName = CostFunctionArray
     DelaunayTessellation = vtkUnstructuredGrid
     VoronoiDiagram = vtkPolyData
     PoleIds = vtkIdList

Re: [vmtk-users] centerlines question

[Luca A. <an...@ma...>]

Hi Joong-Ho,
   glad you're using vmtk, welcome aboard!
The way you ran centerlines looks correct for the most part, except  
that in your case you should use
only one source point and two target points. Source and target points  
need not to be specified in pairs.
If you specify two sources and two targets, you should get four  
lines, two from the first source to both
targets and two from the second source to both targets.
The vtkMath error is usually not critical. It's generated during the  
Delaunay tessellation
and it usually means that the tessellation is not unique, as when  
surface points are organized
regularly (e.g. in a rectilinear or cylindrical lattice).
Feel free to send me your model, so I can give it a try myself. The  
centerline code is in general very robust,
so I'm interested in seeing a case in which it fails.

As to the selection of source and targets:
your model has closed ends because it comes out of levelsets. If you  
want to keep it like this, you're bound
to selecting source and targets the way you did. Note that the  
resulting centerlines won't be affected by
the fine location of your source and target points outside about a  
vessel radius away from them.
If you want to clip the endpoints, you can proceed in two ways (as  
explained in the "From 3D surfaces to CFD meshes" tutorial,
section "Opening the surface"):
- interactively, using vmtksurfaceclipper, which lets you chop a  
model with a sphere
- automatically, using vmtkendpointextractor (with this you first  
compute centerlines with manual source and targets, and then
you chop the enpoints based on the centerline ends)
Once you open the surface, the selection of source and targets is  
performed with the barycenter of open profiles.

Best regards


Luca


--
Luca Antiga, PhD
Biomedical Technologies Laboratory,
Bioengineering Department,
Mario Negri Institute
email: an...@ma...
web: http://villacamozzi.marionegri.it/~luca
mail: Villa Camozzi, 24020, Ranica (BG), Italy
phone: +39 035 4535-381



On Jan 8, 2007, at 6:59 AM, Joong-Ho Won wrote:

> Hi,
>
> I compiled and installed vmtk0.6 on a Windows XP machine. It seems  
> work
> fine, but I have a trouble with using vmtkcenterlines.
>
> I want to extract centerlines of the abdominal aorta and its branches.
> As a simple test, I segmented the aorta (below the heart and above the
> iliac bifurcation) and the right renal artery from a CTA data,  
> resulting
> in a T-shaped branching. Then I obtained a surface model using
> vmtkmarchingcubes (I basically followed the tutorial in the website).
>
> Next, I ran vmtkcenterlines:
>
> vmtkcenterlines.py -ifile p001_part1_model.vtp -ofile
> p001_part1_centerlines2.vtp
>
> as in the tutorial.
>
> As I wanted T-shaped centerlines, I thought that I need two pairs of
> source and target points. I chose both source points to be the  
> same: the
> proximal endpoint of the aorta. Target points are chosen to be the
> distal end of the aorta and the end of the renal artery.
>
> Since the model is a closed surface, I pressed space *twice* on the  
> top
> of the aorta surface to select the source points. For target points I
> pressed space on two different points on the surface, of course.
>
> During centerline extraction, a vtkOutputWindow popped up and  
> complained :
>
> Unable to factor linear system
>
> which was a vmtkMath error.
>
> When I displayed the centerlines (p001_part1_centerlines2.vtp, using
> vmtkcenterlineviewer), I only see a single centerline, which I  
> guess is
> one for the aorta.
>
> I tried again with only a single source point, but the result was  
> the same.
>
> Interestingly, the Voronoi diagram looked fine.
>
> To summarize,
>
> 1. I can't see multiple centerlines.
> 2. I have no confidence on my selection of source and target points
> (what is the precise definition of these points?)
>
> It appears that I made some simple mistake, but can't guess what it  
> is.
> FYI, I attach the output of vmtkcenterlines below. It seems that the
> script produces only one centerline.
>
> Thanks in advance,
>
> Joong-Ho.
>
>
>
> C:\Program Files\VMTK\bin>vmtkcenterlines.py -ifile  
> p001_part1_model.vtp -of
> p001_part1_centerlines2.vtp
>
> Creating vmtkCenterlines instance.
> Automatic piping vmtkcenterlines
> Parsing options vmtkcenterlines
>      SurfaceInputFileName = p001_part1_model.vtp
>      CenterlinesOutputFileName = p001_part1_centerlines2.vtp
> Explicit piping vmtkcenterlines
> Input vmtkcenterlines members:
>      Id = 0
>      Surface = None
>      SurfaceInputFileName = p001_part1_model.vtp
>      SeedSelectorName = pickpoint
>      SourceIds = []
>      TargetIds = []
>      SourcePoints = []
>      TargetPoints = []
>      AppendEndPoints = 0
>      FlipNormals = 0
>      CapDisplacement = 0.1
>      RadiusArrayName = MaximumInscribedSphereRadius
>      AppendEndPoints = 0
>      Resampling = 0
>      ResamplingStepLength = 1.0
>      DelaunayTessellation = None
>      UseTetGen = 0
>      TetGenDetectInter = 1
>      CostFunction = 1/R
>      CenterlinesOutputFileName = p001_part1_centerlines2.vtp
>      DelaunayTessellationOutputFileName =
>      VoronoiDiagramOutputFileName =
> Reading VTK XML surface file.
> Executing vmtkcenterlines ...
> NonManifold check.
> Cleaning surface.
> Triangulating surface.
> Capping surface.
> Please position the mouse and press space to add source points, 'u'  
> to undo
> Please position the mouse and press space to add target points, 'u'  
> to undo
> Computing centerlines.
> Done executing vmtkcenterlines.
> Writing VTK XML surface file.
> Output vmtkcenterlines members:
>      Id = 0
>      Centerlines = vtkPolyData
>      RadiusArrayName = MaximumInscribedSphereRadius
>      EikonalSolutionArrayName = EikonalSolutionArray
>      EdgeArrayName = EdgeArray
>      EdgePCoordArrayName = EdgePCoordArray
>      CostFunctionArrayName = CostFunctionArray
>      DelaunayTessellation = vtkUnstructuredGrid
>      VoronoiDiagram = vtkPolyData
>      PoleIds = vtkIdList
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> vmtk-users mailing list
> vmt...@li...
> https://lists.sourceforge.net/lists/listinfo/vmtk-users

Re: [vmtk-users] centerlines question

[Joong-Ho W. <jh...@st...>]

Hi Luca,

Thanks for timely answers. I further played with the tools and figured 
out that the selection of source/target points were wrong. When 
segmenting vessels, I chose points on the first and the last slices of 
the CT data for the aorta. This resulted in planes parallel to z-axis in 
the surface model. I again chose points on these planes for a source and 
a target points. For some reason, this made the centerline module 
confused. I avoided points on those planes and it worked fine.

Interestingly, those planes disappear when I visualize the model using 
vmtksurfaceviewer with opacity 0.25. I don't know why. Currently I don't 
have the model file with me. I will send them to you soon.

BTW, how can I clip the vessel surface using the output file of 
vmtkbranchextractor? I tried

vmtkbranchclipper -ifile foo.vtp -centerlinefile foo_clsp.vtp -ofile 
foo_sp.vtp

but failed, where foo.vtp is the surface model, foo_cl.vtp is obtained with

vmtkcenterlines -ifile foo.vtp -ofile foo_cl.vtp
vmtkbranchextractor -ifile foo_cl.vtp -ofile foo_clsp.vtp -radiusarray 
MaximumInscribedSphereRadius

Thanks in advance.


joong-ho.



Luca Antiga wrote:
> Hi Joong-Ho,
>   glad you're using vmtk, welcome aboard!
> The way you ran centerlines looks correct for the most part, except that 
> in your case you should use 
> only one source point and two target points. Source and target points 
> need not to be specified in pairs.
> If you specify two sources and two targets, you should get four lines, 
> two from the first source to both
> targets and two from the second source to both targets.
> The vtkMath error is usually not critical. It's generated during the 
> Delaunay tessellation
> and it usually means that the tessellation is not unique, as when 
> surface points are organized
> regularly (e.g. in a rectilinear or cylindrical lattice).
> Feel free to send me your model, so I can give it a try myself. The 
> centerline code is in general very robust, 
> so I'm interested in seeing a case in which it fails.
> 
> As to the selection of source and targets:
> your model has closed ends because it comes out of levelsets. If you 
> want to keep it like this, you're bound 
> to selecting source and targets the way you did. Note that the resulting 
> centerlines won't be affected by 
> the fine location of your source and target points outside about a 
> vessel radius away from them.
> If you want to clip the endpoints, you can proceed in two ways (as 
> explained in the "From 3D surfaces to CFD meshes" tutorial, 
> section "Opening the surface"): 
> - interactively, using vmtksurfaceclipper, which lets you chop a model 
> with a sphere
> - automatically, using vmtkendpointextractor (with this you first 
> compute centerlines with manual source and targets, and then
> you chop the enpoints based on the centerline ends)
> Once you open the surface, the selection of source and targets is 
> performed with the barycenter of open profiles.
> 
> Best regards
> 
> 
> Luca
> 
> 
> --
> Luca Antiga, PhD
> Biomedical Technologies Laboratory,
> Bioengineering Department,
> Mario Negri Institute
> email: an...@ma... <mailto:an...@ma...>
> web: http://villacamozzi.marionegri.it/~luca
> mail: Villa Camozzi, 24020, Ranica (BG), Italy
> phone: +39 035 4535-381
> 

Re: [vmtk-users] centerlines question

[Luca A. <an...@ma...>]

Hi Joong-Ho,
   good that it worked, but the issue is worth further investigation.
Let me know when you can send the file over.

The branch clipper has to know what arrays to base the splitting on.
The quickest thing you can do in this case is pipe the clipper after  
the extractor
(in this case don't forget to remove the -ifile and -centerlinesfile  
options)

Ciao

Luca


--
Luca Antiga, PhD
Biomedical Technologies Laboratory,
Bioengineering Department,
Mario Negri Institute
email: an...@ma...
web: http://villacamozzi.marionegri.it/~luca
mail: Villa Camozzi, 24020, Ranica (BG), Italy
phone: +39 035 4535-381



On Jan 9, 2007, at 1:08 AM, Joong-Ho Won wrote:

> Hi Luca,
>
> Thanks for timely answers. I further played with the tools and  
> figured out that the selection of source/target points were wrong.  
> When segmenting vessels, I chose points on the first and the last  
> slices of the CT data for the aorta. This resulted in planes  
> parallel to z-axis in the surface model. I again chose points on  
> these planes for a source and a target points. For some reason,  
> this made the centerline module confused. I avoided points on those  
> planes and it worked fine.
>
> Interestingly, those planes disappear when I visualize the model  
> using vmtksurfaceviewer with opacity 0.25. I don't know why.  
> Currently I don't have the model file with me. I will send them to  
> you soon.
>
> BTW, how can I clip the vessel surface using the output file of  
> vmtkbranchextractor? I tried
>
> vmtkbranchclipper -ifile foo.vtp -centerlinefile foo_clsp.vtp - 
> ofile foo_sp.vtp
>
> but failed, where foo.vtp is the surface model, foo_cl.vtp is  
> obtained with
>
> vmtkcenterlines -ifile foo.vtp -ofile foo_cl.vtp
> vmtkbranchextractor -ifile foo_cl.vtp -ofile foo_clsp.vtp - 
> radiusarray MaximumInscribedSphereRadius
>
> Thanks in advance.
>
>
> joong-ho.
>
>
>
> Luca Antiga wrote:
>> Hi Joong-Ho,
>>   glad you're using vmtk, welcome aboard!
>> The way you ran centerlines looks correct for the most part,  
>> except that in your case you should use only one source point and  
>> two target points. Source and target points need not to be  
>> specified in pairs.
>> If you specify two sources and two targets, you should get four  
>> lines, two from the first source to both
>> targets and two from the second source to both targets.
>> The vtkMath error is usually not critical. It's generated during  
>> the Delaunay tessellation
>> and it usually means that the tessellation is not unique, as when  
>> surface points are organized
>> regularly (e.g. in a rectilinear or cylindrical lattice).
>> Feel free to send me your model, so I can give it a try myself.  
>> The centerline code is in general very robust, so I'm interested  
>> in seeing a case in which it fails.
>> As to the selection of source and targets:
>> your model has closed ends because it comes out of levelsets. If  
>> you want to keep it like this, you're bound to selecting source  
>> and targets the way you did. Note that the resulting centerlines  
>> won't be affected by the fine location of your source and target  
>> points outside about a vessel radius away from them.
>> If you want to clip the endpoints, you can proceed in two ways (as  
>> explained in the "From 3D surfaces to CFD meshes" tutorial,  
>> section "Opening the surface"): - interactively, using  
>> vmtksurfaceclipper, which lets you chop a model with a sphere
>> - automatically, using vmtkendpointextractor (with this you first  
>> compute centerlines with manual source and targets, and then
>> you chop the enpoints based on the centerline ends)
>> Once you open the surface, the selection of source and targets is  
>> performed with the barycenter of open profiles.
>> Best regards
>> Luca
>> --
>> Luca Antiga, PhD
>> Biomedical Technologies Laboratory,
>> Bioengineering Department,
>> Mario Negri Institute
>> email: an...@ma... <mailto:an...@ma...>
>> web: http://villacamozzi.marionegri.it/~luca
>> mail: Villa Camozzi, 24020, Ranica (BG), Italy
>> phone: +39 035 4535-381

Re: [vmtk-users] centerlines question

[Luca A. <an...@ma...>]

Hi Joong-Ho,
   for some reason the vtp file you attached was embedded in the  
message. I tried to delete the rest and keep the attached data, but  
it's invalid because there are spurious carriage returns around.
You could try to tar.gz the file and then attach it.

As to the pipe, just a quick suggestion (a feature of pypes you might  
have missed):
when you specify a variable that has to be repeated downstream the  
pipe, you can "push" it the first time you specify it, this way

> vmtkbranchextractor.py -ifile p001_part1_centerlines.vtp \
> -radiusarray@ MaximumInscribedSphereRadius \
> --pipe vmtkbranchclipper.py -ifile p001_part1_model.vtp \
> --pipe vmtksurfaceviewer -array GroupIds

In this pipe, -radiusarray@ will be pushed along the pipe and  
recognized by vmtkbranchclipper.

> But I failed to do this without vmtkbranchextractor in front of  
> vmtkbranchclipper, i.e. using the output file of vmtkbranchextractor.
Sorry, I don't understand what you mean :-) Could you be more specific?

I have to run now, I'll come back later to reply to your last question

Luca

--
Luca Antiga, PhD
Biomedical Technologies Laboratory,
Bioengineering Department,
Mario Negri Institute
email: an...@ma...
web: http://villacamozzi.marionegri.it/~luca
mail: Villa Camozzi, 24020, Ranica (BG), Italy
phone: +39 035 4535-381



On Jan 10, 2007, at 11:14 AM, Joong-Ho Won wrote:
> Hi Luca,
>
> I was just about to send you the files! Here I attach a segmented  
> image and a model obtained by running marching cubes on the image.
>
> As for branchclipper, I made something like the following work:
>
> vmtkbranchextractor.py -ifile p001_part1_centerlines.vtp \
> -radiusarray MaximumInscribedSphereRadius \
> --pipe vmtkbranchclipper.py -ifile p001_part1_model.vtp \
> -radiusarray MaximumInscribedSphereRadius \
> --pipe vmtksurfaceviewer -array GroupIds
>
> where p001_part1_centerlines.vtp is the centerlines obtained using  
> vmtkcenterlines. But I failed to do this without  
> vmtkbranchextractor in front of vmtkbranchclipper, i.e. using the  
> output file of vmtkbranchextractor.
>
> One more question:
>
> Given the (grouped) centerlines, I would like to read the  
> coordinates of the sample points and the radius of the max  
> inscribed sphere on each centerline, mostly having MATLAB in mind.  
> How can I do this?
>
> Thank you,
>
>    Joong-Ho.
>
>
>
> Luca Antiga wrote:
>> Hi Joong-Ho,
>>   good that it worked, but the issue is worth further  
>> investigation. Let me know when you can send the file over.
>> The branch clipper has to know what arrays to base the splitting on.
>> The quickest thing you can do in this case is pipe the clipper  
>> after the extractor
>> (in this case don't forget to remove the -ifile and - 
>> centerlinesfile options)
>> Ciao
>> Luca





--
Luca Antiga, PhD
Biomedical Technologies Laboratory,
Bioengineering Department,
Mario Negri Institute
email: an...@ma...
web: http://villacamozzi.marionegri.it/~luca
mail: Villa Camozzi, 24020, Ranica (BG), Italy
phone: +39 035 4535-381

Re: [vmtk-users] centerlines question

[Luca A. <an...@ma...>]

Hi Joong-Ho, I see that your surface is quite noisy, and it certainly  
depends on the initial image quality.
You may want to use the -featurederivativesigma option on the  
vmtklevelsetsegmentation command line and set a nonzero curvature  
weight during levelset evolution. This may help you getting a  
smoother surface.
Now, I tried the branch clipping with the following pipe:

vmtksurfacereader -ifile p001_part1_model.vtp --pipe vmtkcenterlines  
--pipe vmtkbranchextractor --pipe vmtkbranchclipper --pipe  
vmtksurfaceviewer -array GroupIds

(you can add as many ofile as you want, I didn't do it since I was  
interested in viewing the result)

and it worked per se, although the splitting has a defect due to  
surface irregularities (two small regions on one branch are assigned  
to the other). I'll have to take care of this sooner than later, it's  
a known issue and I think I know how to fix it to make it more  
bulletproof even with noisy or weird shaped datasets.
Probably the bug won't show up if you regularize the image during  
segmentation the way I suggested at the beginning of this mail.

As to the reason why your script failed, is that if you don't use it  
in a pipe it has no way of knowing what's the array name that  
vmtkbranchextractor generated for storing the GroupIds and other  
splitting related arrays (to ease the user's life I may decide in the  
future to give this kind of information a meaningful default that  
would work in most of the cases).
If you really want to avoid using it in a pipe, you have to specify
vmtkbranchclipper -ifile p001_part1_model.vtp -centerlinesfile  
p001_part1_tracts.vtp -radiusarray MaximumInscribedSphereRadius - 
groupidsarray GroupIds -blankingarray Blanking --pipe  
vmtksurfaceviewer -array GroupIds
but I suggest that you simply use it piped after vmtkbranchsplitting,  
as all this information passing will be taken care of for you.

Cheers

Luca


--
Luca Antiga, PhD
Biomedical Technologies Laboratory,
Bioengineering Department,
Mario Negri Institute
email: an...@ma...
web: http://villacamozzi.marionegri.it/~luca
mail: Villa Camozzi, 24020, Ranica (BG), Italy
phone: +39 035 4535-381



On Jan 10, 2007, at 2:18 PM, Joong-Ho Won wrote:

> Hello Luca,
>
> I attach them again in tgz (Windows extension for tar.gz) format.
>
> For the vmtkbranchclipper, I meant first run
>
> vmtkbranchextractor.py -ifile p001_part1_centerlines.vtp -ofile  
> p001_part1_tracts.vtp \
> -radiusarray MaximumInscribedSphereRadius
>
> and
>
> vmtkbranchclipper.py -ifile p001_part1_model.vtp \
> -centerlinesfile p001_part1_tracts.vtp \
> -radiusarray MaximumInscribedSphereRadius \
> --pipe vmtksurfaceviewer -array GroupIds
>
> The second one failed with "CenterlineGroupdIdsArray with name  
> specified does not exist."
>
> Regards,
>
>    Joong-Ho.
>
>
> Luca Antiga wrote:
>> Hi Joong-Ho,
>>   for some reason the vtp file you attached was embedded in the  
>> message. I tried to delete the rest and keep the attached data,  
>> but it's invalid because there are spurious carriage returns around.
>> You could try to tar.gz the file and then attach it.
>> As to the pipe, just a quick suggestion (a feature of pypes you  
>> might have missed):
>> when you specify a variable that has to be repeated downstream the  
>> pipe, you can "push" it the first time you specify it, this way
>>> vmtkbranchextractor.py -ifile p001_part1_centerlines.vtp \
>>> -radiusarray@ MaximumInscribedSphereRadius \
>>> --pipe vmtkbranchclipper.py -ifile p001_part1_model.vtp \
>>> --pipe vmtksurfaceviewer -array GroupIds
>> In this pipe, -radiusarray@ will be pushed along the pipe and  
>> recognized by vmtkbranchclipper.
>>> But I failed to do this without vmtkbranchextractor in front of  
>>> vmtkbranchclipper, i.e. using the output file of  
>>> vmtkbranchextractor.
>> Sorry, I don't understand what you mean :-) Could you be more  
>> specific?
>> I have to run now, I'll come back later to reply to your last  
>> question
>> Luca
>> <vmtkdata.tgz>

Re: [vmtk-users] centerlines question

[Luca A. <an...@ma...>]

Just one more quick thing:

the splitting bug goes away even with your model if you smooth it first

vmtksurfacereader -ifile p001_part1_model.vtp --pipe  
vmtksurfacesmoothing -iterations 30 -passband 0.015 --pipe  
vmtkcenterlines --pipe vmtkbranchextractor --pipe vmtkbranchclipper -- 
pipe vmtksurfaceviewer -array GroupIds

Take this as a temporary workaround...

Luca

--
Luca Antiga, PhD
Biomedical Technologies Laboratory,
Bioengineering Department,
Mario Negri Institute
email: an...@ma...
web: http://villacamozzi.marionegri.it/~luca
mail: Villa Camozzi, 24020, Ranica (BG), Italy
phone: +39 035 4535-381



On Jan 10, 2007, at 2:18 PM, Joong-Ho Won wrote:

> Hello Luca,
>
> I attach them again in tgz (Windows extension for tar.gz) format.
>
> For the vmtkbranchclipper, I meant first run
>
> vmtkbranchextractor.py -ifile p001_part1_centerlines.vtp -ofile  
> p001_part1_tracts.vtp \
> -radiusarray MaximumInscribedSphereRadius
>
> and
>
> vmtkbranchclipper.py -ifile p001_part1_model.vtp \
> -centerlinesfile p001_part1_tracts.vtp \
> -radiusarray MaximumInscribedSphereRadius \
> --pipe vmtksurfaceviewer -array GroupIds
>
> The second one failed with "CenterlineGroupdIdsArray with name  
> specified does not exist."
>
> Regards,
>
>    Joong-Ho.
>
>
> Luca Antiga wrote:
>> Hi Joong-Ho,
>>   for some reason the vtp file you attached was embedded in the  
>> message. I tried to delete the rest and keep the attached data,  
>> but it's invalid because there are spurious carriage returns around.
>> You could try to tar.gz the file and then attach it.
>> As to the pipe, just a quick suggestion (a feature of pypes you  
>> might have missed):
>> when you specify a variable that has to be repeated downstream the  
>> pipe, you can "push" it the first time you specify it, this way
>>> vmtkbranchextractor.py -ifile p001_part1_centerlines.vtp \
>>> -radiusarray@ MaximumInscribedSphereRadius \
>>> --pipe vmtkbranchclipper.py -ifile p001_part1_model.vtp \
>>> --pipe vmtksurfaceviewer -array GroupIds
>> In this pipe, -radiusarray@ will be pushed along the pipe and  
>> recognized by vmtkbranchclipper.
>>> But I failed to do this without vmtkbranchextractor in front of  
>>> vmtkbranchclipper, i.e. using the output file of  
>>> vmtkbranchextractor.
>> Sorry, I don't understand what you mean :-) Could you be more  
>> specific?
>> I have to run now, I'll come back later to reply to your last  
>> question
>> Luca
>> <vmtkdata.tgz>

Re: [vmtk-users] centerlines question

[Luca A. <an...@ma...>]

Hi Jong-Ho,
   glad you're being successful with your analysis.
First a suggestion: if you need to spit out your data in a CSV-like  
format, you can use the pointdata format. You can do it by naming  
your output file with a .dat extension.
As to centerlines and branches, you're right, in general there's more  
than one cell per branch. If you look at the pictures of the branch  
splitting tutorial (http://villacamozzi.marionegri.it/~luca/vmtk/ 
doku.php?id=vmtk:vmtk_tutorials:branch_splitting) you can figure out  
why: each vmtk centerline is defined from an inlet to an outlet. If  
you have a single bifurcation, the upstream branch will be defined by  
both cells corresponding to the two centerlines, while the downstream  
branches will be made up by one cell each. The two cells of the  
upstream branch are mostly coincident, except in the bifurcation  
region. How early and how much they depart depends on the shape of  
the bifurcation region.
This is a feature that's very useful in handling complex branching  
situations, and it's the basis of geometric analysis of bifurcations.  
However, I also understand that one may want to have a unique  
definition... let me know what you have to do with your coordinates,  
I can maybe help out.
Anyway, in order to find out which cells belong to which branch, you  
can use the GroupIds array (refer to the tutorial for an explanation).
If you need to extract points at the same abscissa at every cell of a  
branch, run centerlines through vmtkcenterlineattributes, which will  
compute abscissas along centerlines. If you run it before splitting  
and then split branches, abscissas will start at zero at the inlets,  
and then progress along every branch. If you run it after splitting,  
every branch will start at zero. Once you have the abscissas, every  
cell with the same group id will have correspondent points at the  
same abscissas (Now that I think about it, vmtk should have a filter  
that uses this criterion to generate a "one cell per branch" version  
of centerlines).
Let me know what's your purpose, so I can be more specific.

A last point: for some reason your vtp attachments are embedded in  
messages and I can't save them properly. Could you please first zip  
them and then attach?

Cheers

Luca


--
Luca Antiga, PhD
Biomedical Technologies Laboratory,
Bioengineering Department,
Mario Negri Institute
email: an...@ma...
web: http://villacamozzi.marionegri.it/~luca
mail: Villa Camozzi, 24020, Ranica (BG), Italy
phone: +39 035 4535-381



On Jan 22, 2007, at 8:54 AM, Joong-Ho Won wrote:
> Hi Luca,
>
> I tested your tip and the results look much better. Thanks a lot.
>
> This time I have a different question. Basically I want to utilize  
> the branch analysis capability of vmtk, so that I can use the  
> output of vmtkbranchextractor in MATLAB. Since the output is  
> written in .vtp format, I decided to write a python script to  
> examine the content of the output file and produces a bunch of CSV  
> files containing the coordinates of centerlines and so on.
>
> What I would like to do is to access the centerline of each group.  
> I assumed each vtk cell corresponds to each group and it seemed to  
> work with small number of branches. But I soon found out that my  
> assumption was wrong and that there can be more cells than the  
> number of groups. It appears that each cell represents a polyline  
> that is a part of a group, but I have no idea of how these  
> polylines of the same group are arranged in .vtp file. To  
> reconstruct the centerline of a group, what should I do?
>
> Just in case, I attach the model vtp file, splitted centerlines vtp  
> file, and my script. Hope there is a solution.
>
>
> Regards,
>
>    Joong-Ho.
>
>

Re: [vmtk-users] centerlines question

[Luca A. <an...@ma...>]

Hey Joong-Ho,
  nice model. As a further suggestion, you could use a larger  
curvature weight on the aorta (while the branches look good), in  
order to get rid of the surface wobbles.
For visualizing maximal inscribed spheres, the quick and dirty way I  
use is using glyphs.
You can do it in Paraview (www.paraview.org), or by running something  
like


import vtk

reader = vtk.vtkXMLPolyDataReader()
reader.SetFileName("foo_centerlines.vtp")
reader.Update()

reader.GetOutput().GetPointData().SetActiveScalars 
("MaximumInscribedSphereRadius")

sphere = vtk.vtkSphereSource()
sphere.SetThetaResolution(12)
sphere.SetPhiResolution(12)

glyphs = vtk.vtkGlyph3D()
glyphs.SetInput(reader.GetOutput())
glyphs.SetSource(sphere.GetOutput())
glyphs.ScalingOn()
glyphs.SetScaleModeToScaleByScalar()
glyphs.SetScaleFactor(2.0)

writer = vtk.vtkXMLPolyDataWriter()
writer.SetInput(glyphs.GetOutput())
writer.SetFileName("foo_glyphs.vtp")
writer.Write()


Also, in the model I see that the model is artifactually narrowed at  
a curve along the celiac.
This is probably due to the initialization not filling the vessel  
completely.
When this happens, you either resegment the missing bit, or rerun the  
levelsets for the celiac
giving it a small but nonzero (say, 0.01 or 0.1) propagation weight.

As to the single centerline representing the branch, you're right, it  
would be handy to have one.
Except that single centerlines wouldn't naturally meet at  
bifurcations (but if I understand it properly,
this wouldn't necessarily be an issue).
Let me look into it, I may be able to code this tonight and let you  
know tomorrow

Luca


--
Luca Antiga, PhD
Biomedical Technologies Laboratory,
Bioengineering Department,
Mario Negri Institute
email: an...@ma...
web: http://villacamozzi.marionegri.it/~luca
mail: Villa Camozzi, 24020, Ranica (BG), Italy
phone: +39 035 4535-381



On Jan 22, 2007, at 10:59 PM, Joong-Ho Won wrote:

> Hi Luca,
>
> Thanks again. I understood how it works. So even with a simple Y- 
> shaped branches, I should have 4 cells even though there are 3 groups.
>
> What I am trying to get is to have a unique and robust descriptor  
> for each group, so that I can play with only one centerline in  
> processing individual branch.
>
> I attach a .tgz file for those (failed) files :)
>
> BTW, is it possible to visualize tube surfaces bases on the  
> centerlines and the maximum inscribing sphere radii? That should be  
> a form is distance surface. I would like to see how closely it  
> approximate the original surface obtained by levelsets and marching  
> cubes.
>
> I really appreciate your responsiveness.
>
> Best,
>
>    Joong-Ho.
>
>
> Luca Antiga wrote:
>> Hi Jong-Ho,
>>   glad you're being successful with your analysis.
>> First a suggestion: if you need to spit out your data in a CSV- 
>> like format, you can use the pointdata format. You can do it by  
>> naming your output file with a .dat extension.
>> As to centerlines and branches, you're right, in general there's  
>> more than one cell per branch. If you look at the pictures of the  
>> branch splitting tutorial (http://villacamozzi.marionegri.it/~luca/ 
>> vmtk/doku.php?id=vmtk:vmtk_tutorials:branch_splitting) you can  
>> figure out why: each vmtk centerline is defined from an inlet to  
>> an outlet. If you have a single bifurcation, the upstream branch  
>> will be defined by both cells corresponding to the two  
>> centerlines, while the downstream branches will be made up by one  
>> cell each. The two cells of the upstream branch are mostly  
>> coincident, except in the bifurcation region. How early and how  
>> much they depart depends on the shape of the bifurcation region.
>> This is a feature that's very useful in handling complex branching  
>> situations, and it's the basis of geometric analysis of  
>> bifurcations. However, I also understand that one may want to have  
>> a unique definition... let me know what you have to do with your  
>> coordinates, I can maybe help out.
>> Anyway, in order to find out which cells belong to which branch,  
>> you can use the GroupIds array (refer to the tutorial for an  
>> explanation).
>> If you need to extract points at the same abscissa at every cell  
>> of a branch, run centerlines through vmtkcenterlineattributes,  
>> which will compute abscissas along centerlines. If you run it  
>> before splitting and then split branches, abscissas will start at  
>> zero at the inlets, and then progress along every branch. If you  
>> run it after splitting, every branch will start at zero. Once you  
>> have the abscissas, every cell with the same group id will have  
>> correspondent points at the same abscissas (Now that I think about  
>> it, vmtk should have a filter that uses this criterion to generate  
>> a "one cell per branch" version of centerlines).
>> Let me know what's your purpose, so I can be more specific.
>> A last point: for some reason your vtp attachments are embedded in  
>> messages and I can't save them properly. Could you please first  
>> zip them and then attach?
>> Cheers
>> Luca
>> <centerlines.tgz>

Re: [vmtk-users] centerlines question

[Luca A. <an...@ma...>]

Hey Joong-Ho,
  thanks for reporting. I noticed this a few days ago.
Indeed this is a issue with ITK. ITK developers are used to derive  
classes and build against the built version of ITK.
In the build tree, those included files are in fact in Utilities/ 
itkExtHdrs. However, during make install the itkExtHdrs directory  
disappears, and all files are placed in /usr/local/include/ 
InsightToolkit/Utilities.
Therefore, the quick workaround is to build against the built ITK  
version.

I'll file a bug report to the ITK guys, this thing should be fixed.

Thanks a lot and let me know if you need anything.


Luca


PS: by the way, which compiler are you using under Windows?


--
Luca Antiga, PhD
Biomedical Technologies Laboratory,
Bioengineering Department,
Mario Negri Institute
email: an...@ma...
web: http://villacamozzi.marionegri.it/~luca
mail: Villa Camozzi, 24020, Ranica (BG), Italy
phone: +39 035 4535-381



On Jan 25, 2007, at 10:36 PM, Joong-Ho Won wrote:

> Hi Luca,
>
> It worked very well, and the results are exactly what I wanted. I  
> really appreciate your help.
>
> BTW, I had some minor troubles in compiling the source. Some ITK  
> headers (itkAnalyzeImageIO.h, itkGE5ImageIO.h) look for headers in  
> itkExtHdrs subdirectory, but they are in fact in Utilities  
> subdirectory. I think this is the problem of ITK, not VMTK. But I  
> just wanted to let you know. I use ITK3.0 on Windows XP.
>
> Thanks again,
>
>    Joong-Ho.
>
>
> Luca Antiga wrote:
>> Hi Joong-Ho,  last night I coded in a class that does what you  
>> were looking for.
>> I attach the new vmtk code.
>> Since there has been a change in this version on how python  
>> modules are organized (it's much more pythonic now), you're  
>> required to clean your /usr/local/lib/vmtk directory before  
>> installing this version. This has just to be done the first time,  
>> of course.
>> The class that lumps branches into single centerline tracts is  
>> called vmtkcenterlinemerge. You have to provide split centerlines  
>> and it will generate a line for each branch (bifurcation tracts  
>> are excluded), preserving group ids:
>> vmtkcenterlinemerge -ifile foo_tracts.vtp -groupidsarray GroupIds - 
>> blankingarray Blanking -radiusarray MaximumInscribedSphereRadius - 
>> length 0.01 -ofile foo_merged.vtp
>> The -length option is relative to the length of the step with  
>> which you resample centerlines (resampling is used to generate  
>> coincident points on the different cells of a branch).
>> Then you can display centerlines this way
>> vmtkcenterlineviewer -ifile foo_merged.vtp -cellarray GroupIds
>> to know what groupid is what.
>> Let me know if this works for you
>> Luca

Re: [vmtk-users] centerlines question

[Luca A. <an...@ma...>]

Hi Joong-Ho,
  after checking with Luis Ibanez, I found out that the problem has  
been fixed in the current ITK stable version (3.0.1)
I compile it and I confirm that the problem is gone.
Ciao

Luca

--
Luca Antiga, PhD
Biomedical Technologies Laboratory,
Bioengineering Department,
Mario Negri Institute
email: an...@ma...
web: http://villacamozzi.marionegri.it/~luca
mail: Villa Camozzi, 24020, Ranica (BG), Italy
phone: +39 035 4535-381



On Jan 26, 2007, at 10:17 PM, Joong-Ho Won wrote:

> Hi Luca,
>
> It's good to know that that is not a problem of mine only. FYI, I  
> use Visual Studio 2005 (not Express) on Windows XP.
>
> Have a nice weekend~
>
>
>    Joong-Ho.
>
>
> Luca Antiga wrote:
>> Hey Joong-Ho,
>>  thanks for reporting. I noticed this a few days ago.
>> Indeed this is a issue with ITK. ITK developers are used to derive  
>> classes and build against the built version of ITK.
>> In the build tree, those included files are in fact in Utilities/ 
>> itkExtHdrs. However, during make install the itkExtHdrs directory  
>> disappears, and all files are placed in /usr/local/include/ 
>> InsightToolkit/Utilities. Therefore, the quick workaround is to  
>> build against the built ITK version.
>> I'll file a bug report to the ITK guys, this thing should be fixed.
>> Thanks a lot and let me know if you need anything.
>> Luca
>> PS: by the way, which compiler are you using under Windows?

[vmtk-users] dealing with large data

[Joong-Ho W. <jh...@st...>]

Hi Luca,

Thanks for the notice. I will use 3.0.1 next time I compile VMTK (hope 
it's not too soon :) ).

Now I'm working on real datasets. They are scans of abdominal aorta and 
iliac arteries. Each dataset is made of 600-1000+ dicom files.

As you may have guessed, there is a memory problem. vmtkimagereader 
couldn't read more than 495 slices. So I dropped some chunks and was 
able to load them. VOI selector worked well, and the next task is level 
set segmentation.

It seem to be working, but after segmenting the first branch, when I 
tried initial segmentation, VMTK reported out of memory and nothing 
happened. That same thing happened even though I save the first 
segmentation and continued segmentation using -levelsetsfile option.

My desktop has 2GB of memory, and this is the physical limit of the 
hardware. Maybe the only solution is to split them into several parts 
and merge the results.

So I wonder if it is possible:

1. merge segmentation files off-line, that is, outside of 
vmtklevelsetsegmentation.

2. merge centerlines

It seems 2 should be enough for my purpose, but when I tested with 
splitting, the origins didn't match. It appears that vmtkimagereader has 
-origin option, but they are not for dicom format.

Could you figure out a solution? Thanks.

Regards,

    Joong-Ho.



Luca Antiga wrote:
> Hi Joong-Ho, 
>  after checking with Luis Ibanez, I found out that the problem has been 
> fixed in the current ITK stable version (3.0.1)
> I compile it and I confirm that the problem is gone.
> Ciao
> 
> Luca
> 

Re: [vmtk-users] dealing with large data

[Luca A. <an...@ma...>]

Hi Joong-Ho,
  let's say there are several levels at which the problem of large  
files can be tackled.
One thing you must be aware of is that level sets take a lot of  
memory, mainly for storing
the original image, the gradient magnitude image, and the gradient  
image (for the advection term).
Just these take up 4x the memory of the original image. There's not a  
whole lot you can do about this.
However, you managed to segment the first chunk of data, which is  
promising.
The second thing is that colliding fronts takes even more memory  
during the initialization, so expect
your memory usage to go up. For your information, fast marching takes  
than colliding fronts, thresholding
less than fast marching and isosurface less than thresholding.
Another suggestion is on the system: free up space on the hard drive  
for hosting your virtual memory file.
It's better if your PC starts swapping than just killing the  
application because memory is full.

Now, on to the solutions:
It is definetly possible to segment in chunks and then merge after  
the fact. Or you could segment on lower
resolution images and then optimize non interactively on full  
resolution. Let's explore the various possibilities.

1. Segmenting one vessel at a time on the full image and merging the  
results:
Use vmtklevelsetsegmentation as usual. Then merge the resulting  
levelsets files with
vmtkimagecompose -ifile foo_ls1.vti -i2file foo_ls2.vti -operation  
min -ofile foo_ls12.vti
Eventually, you can do it in sequence
vmtkimagecompose -ifile foo_ls1.vti -i2file foo_ls2.vti -operation  
min --pipe vmtkimagecompose -i2file foo_ls3.vti -ofile foo_ls123.vti
and so on.

2. Generating small VOIs, segmenting all vessels in each VOI and  
merging the results:
Use vmtklevelsetsegmentation as usual on each small VOI. I suggest to  
generate VOIs that have at least a small overlap,
so the segmented vessels will merge seamlessly.
Once you have your segmentations on the small VOIs, you have to  
sample them on a larger canvas and then merge them
as in the previous point.
vmtkimagereslice -ifile foo_ls1.vti -rfile originalimage.vti - 
background -4.0 -ofile foo_ls1re.vti
Here original image is the full image: it's just used to provide the  
origin/spacing/extent information for the resampling, i.e. the
size and position of the canvas.
Do this for every image, then merge all re images as in 1.

3. Segmenting the full image at low resolution and optimizing the  
result on high resolution non-interactively:
this is the solution I suggest the most. Probably your acquired image  
has a resolution that goes well beyond what you actually
need to depict the aorta and the iliacs. Of course the more  
resolution the marrier, but you could use a lower resolution image
to perform your segmentation quickly and interactively, without  
bringing down the system in the process. Then resample the
ls file to full resolution and use it as initiallevelsets for the  
final non-interactive optimization of your segmentation on the full
resolution image. Let's start by resampling the image:
vmtkimagereslice -ifile originalimage.vti -spacing 1.0 1.0 1.0 -ofile  
resampledimage.vti
Then run vmtklevelsetsegmentation on resampledimage.vti (here I set  
isotropic resolution of 1.0mm, but you can of course choose
otherwise).
Once you're done and you've got your foo_ls.vti levelsets file,  
resample it at full resolution
vmtkimagereslice -ifile foo_ls.vti -rfile originalimage.vti -ofile  
foo_lsre.vti

and, last, run vmtklevelsetsegmentation

vmtklevelsetsegmentation -ifile originalimage.vti - 
initiallevelsetsfile foo_lsre.vti -iterations 300 -advectionweight  
1.0 -ofile foo_ls.vti
In this way, no rendering window will come up. Level sets will evolve  
with the iterations and weights you specify at command line,
and will be initialized with foo_lsre.vti

I hope you can find the right solution for your needs among the three  
of these.

Best

Luca


--
Luca Antiga, PhD
Biomedical Technologies Laboratory,
Bioengineering Department,
Mario Negri Institute
email: an...@ma...
web: http://villacamozzi.marionegri.it/~luca
mail: Villa Camozzi, 24020, Ranica (BG), Italy
phone: +39 035 4535-381



On Feb 3, 2007, at 2:10 AM, Joong-Ho Won wrote:

> Hi Luca,
>
> Thanks for the notice. I will use 3.0.1 next time I compile VMTK (hope
> it's not too soon :) ).
>
> Now I'm working on real datasets. They are scans of abdominal aorta  
> and
> iliac arteries. Each dataset is made of 600-1000+ dicom files.
>
> As you may have guessed, there is a memory problem. vmtkimagereader
> couldn't read more than 495 slices. So I dropped some chunks and was
> able to load them. VOI selector worked well, and the next task is  
> level
> set segmentation.
>
> It seem to be working, but after segmenting the first branch, when I
> tried initial segmentation, VMTK reported out of memory and nothing
> happened. That same thing happened even though I save the first
> segmentation and continued segmentation using -levelsetsfile option.
>
> My desktop has 2GB of memory, and this is the physical limit of the
> hardware. Maybe the only solution is to split them into several parts
> and merge the results.
>
> So I wonder if it is possible:
>
> 1. merge segmentation files off-line, that is, outside of
> vmtklevelsetsegmentation.
>
> 2. merge centerlines
>
> It seems 2 should be enough for my purpose, but when I tested with
> splitting, the origins didn't match. It appears that  
> vmtkimagereader has
> -origin option, but they are not for dicom format.
>
> Could you figure out a solution? Thanks.
>
> Regards,
>
>     Joong-Ho.
>
>
>
> Luca Antiga wrote:
>> Hi Joong-Ho,
>>  after checking with Luis Ibanez, I found out that the problem has  
>> been
>> fixed in the current ITK stable version (3.0.1)
>> I compile it and I confirm that the problem is gone.
>> Ciao
>>
>> Luca
>>
>
> ---------------------------------------------------------------------- 
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> vmtk-users mailing list
> vmt...@li...
> https://lists.sourceforge.net/lists/listinfo/vmtk-users