vmtk-users

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>

[vmtk-users] Fwd: centerlines question

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

> From: Joong-Ho Won <jh...@st...>
> Date: January 22, 2007 10:59:05 PM GMT+01:00
> To: Luca Antiga <an...@ma...>
> Subject: Re: [vmtk-users] centerlines question
>
> 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

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...>]

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 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...>]

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,
   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

[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,
   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

[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] Linker Error

[Mike h. <ash...@ya...>]

Dear Luca,
Thanks so much for your reply. Sorry for the double
posting to the mailing list.

Now the code compiles without problems. You certainly
found the problem.
Congratulations on the nice work. I've just started
using the toolkit and it has some very nice features.
Thanks for making it available for public use.

Best regards,
--M.H.


--- Luca Antiga <an...@ma...> wrote:

> Dear Mike,
>   thanks for your interest in vmtk and sorry for not
> getting back to
> you earlier.
> Since I don't have access to windows boxes equipped
> with Visual
> Studio, I can only guess here,
> but I think I know what it is.
> In vtkvmtkMath.h, the use of TypeRevisionMacro, a
> macro in in VTK/
> Common/vtkSetGet.h that adds a protected
> void CollectRevisions(ostream& os);
> method to the class, which is what the linker can't
> find, is not
> matched by a CxxRevisionMacro in the cxx file,
> which implements the CollectRevisions method.
> I basically forgot to add the line
>
> vtkCxxRevisionMacro(vtkvmtkMath, "$Revision: 1.0
> $");
>
> in the file vtkvmtkMath.cxx, right after the
> #include "vtkvmtkMath.h"
> line
>
> I just committed the change in the subversion tree.
> Let me know how it works, and thanks for the
> detailed bug report
>
> 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 Dec 25, 2006, at 10:37 AM, Mike hechter wrote:
>
>> Hi,
>> I've been trying to compile VMTK version 0.6b1 (my
>> first try at vmtk), but keep on running into the
> same
>> problem.
>>
>> My configuration:
>>
>> Win32 XP Pro
>> Visual Studio 2005
>> VTK 5.0.2
>> ITK 2.4.1
>> Python 2.5
>> Cmake 2.4.3
>>
>> I get a linker error
>> "Error	2	error LNK2001: unresolved external symbol
>> "protected: virtual void __thiscall
>> vtkvmtkMath::CollectRevisions(class
>> std::basic_ostream<char,struct
> std::char_traits<char>
>>> &)"
>>
>
(?CollectRevisions@vtkvmtkMath@@MAEXAAV?$basic_ostream@DU?
>
>> $char_traits@D@std@@@std@@@Z)
>> vtkvmtkMath.obj	"
>>
>> I made sure that I compiled VTK with shared libs
> and
>> Python wrapping. Python wrapping for vtk runs
> fine.
>>
>> This linker problem is in vtkvmtkCommon.dll
> project
>> only. All the others compile and link successfuly.
> All
>> *.lib are created successfuly. All .dll are
> created
>> successfuly except for vtkvmtkCommon.dll (and
>> vtkvmtkCommonPython.dll when I enable python
> wrapping
>> in vmtk, which I believe is needed for running the
> .py
>> scripts of vmtk).
>>
>> Is there anything I am doing wrong?
>> It seems like a name mangling issue, but I cannot
> be
>> sure why it is only in vtkvmtkMath (which is part
> of
>> vtkvmtkCommon ) when generating shared libraries.
>> Any help would be appreciated.
>>
>> Thanks,
>> --ashraf
>>
>>
>>
>> __________________________________________________
>> Do You Yahoo!?
>> Tired of spam?  Yahoo! Mail has the best spam
> protection around
>> http://mail.yahoo.com
>>
>>
>
----------------------------------------------------------------------
>
>> ---
>> 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
>
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Re: [vmtk-users] Linker Error

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

Dear Mike,
  thanks for your interest in vmtk and sorry for not getting back to  
you earlier.
Since I don't have access to windows boxes equipped with Visual  
Studio, I can only guess here,
but I think I know what it is.
In vtkvmtkMath.h, the use of TypeRevisionMacro, a macro in in VTK/ 
Common/vtkSetGet.h that adds a protected
void CollectRevisions(ostream& os);
method to the class, which is what the linker can't find, is not  
matched by a CxxRevisionMacro in the cxx file,
which implements the CollectRevisions method.
I basically forgot to add the line

vtkCxxRevisionMacro(vtkvmtkMath, "$Revision: 1.0 $");

in the file vtkvmtkMath.cxx, right after the
#include "vtkvmtkMath.h"
line

I just committed the change in the subversion tree.
Let me know how it works, and thanks for the detailed bug report

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 Dec 25, 2006, at 10:37 AM, Mike hechter wrote:

> Hi,
> I've been trying to compile VMTK version 0.6b1 (my
> first try at vmtk), but keep on running into the same
> problem.
>
> My configuration:
>
> Win32 XP Pro
> Visual Studio 2005
> VTK 5.0.2
> ITK 2.4.1
> Python 2.5
> Cmake 2.4.3
>
> I get a linker error
> "Error	2	error LNK2001: unresolved external symbol
> "protected: virtual void __thiscall
> vtkvmtkMath::CollectRevisions(class
> std::basic_ostream<char,struct std::char_traits<char>
>> &)"
> (?CollectRevisions@vtkvmtkMath@@MAEXAAV?$basic_ostream@DU? 
> $char_traits@D@std@@@std@@@Z)
> vtkvmtkMath.obj	"
>
> I made sure that I compiled VTK with shared libs and
> Python wrapping. Python wrapping for vtk runs fine.
>
> This linker problem is in vtkvmtkCommon.dll project
> only. All the others compile and link successfuly. All
> *.lib are created successfuly. All .dll are created
> successfuly except for vtkvmtkCommon.dll (and
> vtkvmtkCommonPython.dll when I enable python wrapping
> in vmtk, which I believe is needed for running the .py
> scripts of vmtk).
>
> Is there anything I am doing wrong?
> It seems like a name mangling issue, but I cannot be
> sure why it is only in vtkvmtkMath (which is part of
> vtkvmtkCommon ) when generating shared libraries.
> Any help would be appreciated.
>
> Thanks,
> --ashraf
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------- 
> ---
> 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

[vmtk-users] Linker Error

[Mike h. <ash...@ya...>]

Hi,
I've been trying to compile VMTK version 0.6b1 (my
first try at vmtk), but keep on running into the same
problem.

My configuration:

Win32 XP Pro
Visual Studio 2005
VTK 5.0.2
ITK 2.4.1
Python 2.5
Cmake 2.4.3

I get a linker error
"Error	2	error LNK2001: unresolved external symbol
"protected: virtual void __thiscall
vtkvmtkMath::CollectRevisions(class
std::basic_ostream<char,struct std::char_traits<char>
> &)"
(?CollectRevisions@vtkvmtkMath@@MAEXAAV?$basic_ostream@DU?$char_traits@D@std@@@std@@@Z)
vtkvmtkMath.obj	"

I made sure that I compiled VTK with shared libs and
Python wrapping. Python wrapping for vtk runs fine.

This linker problem is in vtkvmtkCommon.dll project
only. All the others compile and link successfuly. All
*.lib are created successfuly. All .dll are created
successfuly except for vtkvmtkCommon.dll (and
vtkvmtkCommonPython.dll when I enable python wrapping
in vmtk, which I believe is needed for running the .py
scripts of vmtk).

Is there anything I am doing wrong?
It seems like a name mangling issue, but I cannot be
sure why it is only in vtkvmtkMath (which is part of
vtkvmtkCommon ) when generating shared libraries.
Any help would be appreciated.

Thanks,
--ashraf



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[vmtk-users] Compilation Problem: Unresolved external symbol

[Mike h. <ash...@ya...>]

Hi,
I've been trying to install vmtk for the past few
days, but I keep on running into the same problem.
I have ITK and VTK running without other problems.

When I compile vmtk,I keep on getting a linker error:
"error LNK2001: unresolved external symbol "protected:
virtual void __thiscall
vtkvmtkMath::CollectRevisions(class
std::basic_ostream<char,struct std::char_traits<char>
> &)"
(?CollectRevisions@vtkvmtkMath@@MAEXAAV?$basic_ostream@DU?$char_traits@D@std@@@std@@@Z)
vtkvmtkMath.obj	"
This is in building vtkvmtkCommon.dll and
vtkvmtkCommonPython.dll only. All the remaining dll's
are compiled and linked fine. Also all the .lib are
created fine (including vtkvmtkCommon.lib).

I am using 
Windows32 XP
VTK 5.0.2
VMTK 0.6b1
Visual studio C++ 2005
Python 2.5

I rebuilt VTK with shared libs and python wrapping to
make it work with vmtk. Python wrapping for VTK works.
However, when I try to compile vmtk (with or without
python wrapping and shared libs), I get the linker
error above.


Is there something I am doing wrong?
It seems to me that there is a name mangling problem
that is only in vtkvmtkMath.

Any pointers or suggestions will be much appreciated.
--Ashraf


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[vmtk-users] vmtk-0.6b1 released!

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

Dear users,
   vmtk-0.6b1 has been released.
There is a major change on your side (although not a dramatic one):
all vmtk scripts (imusomething, bvgsomething, bvssomething) have now  
been renamed vmtksomething.
Similarly, vtkBvg, vtkImu, vtkBvs have been merged into vtkVmtk.
This was a necessary cleanup step (and makes my life easier).
Another novelty is that now the development source tree is kept in a  
Subversion repository, not in a CVS
repository. The Installation page on vmtk.sourceforge.net describes  
how to checkout the source code from
the Subversion repository.
Let me know if you bump into any trouble, and thanks for your  
interest in vmtk.
And, by the way, Merry Christmas and a Happy New Year

Luca

Re: [vmtk-users] missing new version?

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

Hey Tiziano,
  thanks for posting.
You're right, I didn't release yet.
Together with Benoit Desjardins we're trying to make vmtk build and  
work smoothly on mac OSX, and I was trying to hold on until I succeeded.
However, I think it's time to release a beta of the next version  
since this situation may generate confusion.
I'll do it before the end of the week
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 Dec 18, 2006, at 4:21 PM, Tiziano Passerini wrote:

> Hi,
>
> I see from VMTK website (Documentation) that the names of the scripts
> have changed in the last version (e. g. imusurfacereader ->
> vmtksurfacereader).
>
> however, I downloaded the binary for the latest release, and it gives:
>
> $> vmtksurfacereader
> No module named vmtksurfacereader
>
> maybe sourceforge holds not the _very_ last version of VMTK :-)
>
> Tiziano
>
> ---------------------------------------------------------------------- 
> ---
> 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

[vmtk-users] missing new version?

[Tiziano P. <pas...@ma...>]

Hi,

I see from VMTK website (Documentation) that the names of the scripts 
have changed in the last version (e. g. imusurfacereader -> 
vmtksurfacereader).

however, I downloaded the binary for the latest release, and it gives:

$> vmtksurfacereader
No module named vmtksurfacereader

maybe sourceforge holds not the _very_ last version of VMTK :-)

Tiziano

Re: [vmtk-users] VMTK installation problem

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

SGkgTmlja29sYXMsIA0KIEkganVzdCBnb3QgYmFjayBmcm9tIHZhY2F0aW9uLCBzb3JyeSBp
ZiBJIGRpZG4ndCByZXBseSB0byB5b3VyDQptZXNzYWdlIGVhcmxpZXIuIA0KIEp1c3QgdG8g
bWFrZSBzdXJlLCBkaWQgeW91IGNvbXBpbGUgVlRLIHdpdGggUFlUSE9OIHdyYXBwaW5nIHR1
cm5lZA0Kb24/IE9uZSBtb3JlIGluZm8sIHdoYXQgQ01ha2UgYW5kIFZUSyB2ZXJzaW9uIGFy
ZSB5b3UgcnVubmluZz8NCiBUaGFua3MNCg0KTHVjYQ0KDQpQUzogSSdtIGNjJ2luZyB0aGlz
IG1lc3NhZ2UgdG8gdGhlIHZtdGstdXNlcnMgbGlzdC4gUGxlYXNlIHBvc3QgeW91cg0KbWVz
c2FnZXMgdGhlcmUuDQoNCg0KDQoNCk9uIEZyaSwgQXVnIDI1LCAyMDA2IGF0IDA4OjEzOjUz
UE0gKzAzMDAsIE4uIFBhdHRha29zIHdyb3RlOg0KPiBIYWxsbywNCj4gDQo+IEkgYW0gTmlj
a29sYXMgUGF0dGFrb3MgYW5kIEkgd29yayB3aXRoIEouIFBhcGFoYXJpbGFvdSBhdCBJQUNN
L0ZPUlRILg0KPiBJIGFtIHNvcnJ5IHRvIGJvdGhlciB5b3UsYnV0IEkgaGF2ZSBiZWVuIHRy
eWluZyB0byBpbnN0YWxsIHZtdGsgNSBvbiBhIA0KPiBsaW51eCBib3ggYW5kIEkgY2FuJ3Qu
IElmIHlvdSBjb3VsZCBoZWxwIG1lLGJlY2F1c2Ugd2Ugd2FudCB0byB1c2Ugdm10ayANCj4g
dG8gbWFrZSBzb21lIG1vZGVscyBmcm9tIHNvbWUgRElDT00gaW1hZ2VzLg0KPiANCj4gSSBy
YW4NCj4gY2NtYWtlIC4uL3ZtdGstNS4wDQo+IA0KPiBhbmQgd2hlbiBJIHByZXNzIGMgdG8g
Y29uZmlndXJlIGl0IHNwaXRzOg0KPiBDTWFrZSBFcnJvcjogRXJyb3IgaW4gY21ha2UgY29k
ZSBhdA0KPiAgOjc6DQo+ICBMT0FEX0NPTU1BTkQgQXR0ZW1wdCB0byBsb2FkIGNvbW1hbmQg
ZmFpbGVkIGZyb20gZmlsZSANCj4gImxpYmNtVlRLX1dSQVBfVENMMi5zbyINCj4gIEN1cnJl
bnQgQ01ha2Ugc3RhY2s6DQo+IA0KPiAvaG9tZS9uc3BhdHRhay9zcmMvdm10ay0wLjUvYnZn
L3Z0a0J2Zy9DTWFrZUxpc3RzLnR4dDsvaG9tZS9uc3BhdHRhay9zcmMvdm10ay0wLjUvYnZn
L3Z0a0J2Zy9DTWFrZU9wdGlvbnMuY21ha2U7L2hvbWUvbnNwYXQNCj4gIHRhay9saWIvbGli
L3Z0ay01LjAvVXNlVlRLLmNtYWtlDQo+IA0KPiAoYW5kIG90aGVyIG1zZ3MgbGlrZSB0aGlz
IG9uZSkNCj4gDQo+IGRvIHlvdSBoYXZlIGFueSBpZGVhPw0KPiANCj4gDQo+IA0KPiANCj4g
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBEZXN0aW5hIGlsIHR1byA1IHBlciBtaWxsZSBk
ZWxsJ0lSUEVGIChzdWwgbW9kLiA3MzAgbyBtb2QuIFVOSUNPDQo+IFBGIG8gbW9kLiBDVUQp
IGNvbiB1bmEgIGZpcm1hIGluZGljYW5kbyBpbCBub3N0cm8gY29kaWNlIGZpc2NhbGUNCj4g
MDMyNTQyMTAxNTAgIHBlciAgYWl1dGFyZSAgYSBtYW50ZW5lcmUgaW5kaXBlbmRlbnRlICBs
YSAgcmljZXJjYQ0KPiBzY2llbnRpZmljYSAgZGVsbCdJc3RpdHV0byAgTWFyaW8gTmVncmks
IHVuYSAgZm9uZGF6aW9uZSBwcml2YXRhDQo+IHNlbnphIHNjb3BvIGRpIGx1Y3JvIGNoZSBk
YSBvbHRyZSA0MCBhbm5pICBvcGVyYSAgbmVsbCdpbnRlcmVzc2UNCj4gZGVnbGkgYW1tYWxh
dGkuDQo+IA0KPiBQZXIgbWFnZ2lvcmkgaW5mb3JtYXppb25pOg0KPiBJc3RpdHV0byBNYXJp
byBOZWdyaSwgVmlhIEVyaXRyZWEgNjIgLSAyMDE1NyBNaWxhbm8NCj4gVGVsOiArMzkgMDIg
MzkwMTQzMTcgLSBGYXg6ICszOSAwMiAzNTQ2Mjc3ICszOSAwMiAzOTAwMTkxOA0KPiBJbnRl
cm5ldDogd3d3Lm1hcmlvbmVncmkuaXQsIG1uZWdyaUBtYXJpb25lZ3JpLml0DQoNCi0tIA0K
THVjYSBBbnRpZ2EsIFBoRA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQ0KQmlvbWVkaWNhbCBUZWNobm9sb2dpZXMgTGFib3JhdG9yeQ0KQmlvZW5n
aW5lZXJpbmcgRGVwYXJ0bWVudCwgDQpNYXJpbyBOZWdyaSBJbnN0aXR1dGUNClZpbGxhIENh
bW96emksIDI0MDIwLCBSYW5pY2EgKEJHKSwgSXRhbHkNCi0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCnBob25lOiArMzkgMDM1IDQ1MzUtMzgxDQpl
bWFpbDogYW50aWdhQG1hcmlvbmVncmkuaXQNCndlYjogICBodHRwOi8vdmlsbGFjYW1venpp
Lm1hcmlvbmVncmkuaXQvfmx1Y2ENCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRGVzdGlu
YSBpbCB0dW8gNSBwZXIgbWlsbGUgZGVsbCdJUlBFRiAoc3VsIG1vZC4gNzMwIG8gbW9kLiBV
TklDTw0KUEYgbyBtb2QuIENVRCkgY29uIHVuYSAgZmlybWEgaW5kaWNhbmRvIGlsIG5vc3Ry
byBjb2RpY2UgZmlzY2FsZQ0KMDMyNTQyMTAxNTAgIHBlciAgYWl1dGFyZSAgYSBtYW50ZW5l
cmUgaW5kaXBlbmRlbnRlICBsYSAgcmljZXJjYQ0Kc2NpZW50aWZpY2EgIGRlbGwnSXN0aXR1
dG8gIE1hcmlvIE5lZ3JpLCB1bmEgIGZvbmRhemlvbmUgcHJpdmF0YQ0Kc2VuemEgc2NvcG8g
ZGkgbHVjcm8gY2hlIGRhIG9sdHJlIDQwIGFubmkgIG9wZXJhICBuZWxsJ2ludGVyZXNzZQ0K
ZGVnbGkgYW1tYWxhdGkuDQoNClBlciBtYWdnaW9yaSBpbmZvcm1hemlvbmk6DQpJc3RpdHV0
byBNYXJpbyBOZWdyaSwgVmlhIEVyaXRyZWEgNjIgLSAyMDE1NyBNaWxhbm8NClRlbDogKzM5
IDAyIDM5MDE0MzE3IC0gRmF4OiArMzkgMDIgMzU0NjI3NyArMzkgMDIgMzkwMDE5MTgNCklu
dGVybmV0OiB3d3cubWFyaW9uZWdyaS5pdCwgbW5lZ3JpQG1hcmlvbmVncmkuaXQ=

[vmtk-users] New vmtk release: 0.5

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

RGVhciB2bXRrLWVycywNCiBJJ20gaGFwcHkgdG8gYW5ub3VuY2UgdGhhdCB2bXRrIGhhcyBy
ZWFjaGVkIDAuNSByZWxlYXNlLg0KU2V2ZXJhbCBidWdzIGhhdmUgYmVlbiBmaXhlZCBhbmQg
bmV3IGZ1bmN0aW9uYWxpdHkgaGFzIGJlZW4gYWRkZWQuDQpNb3Jlb3ZlciwgdGhhbmtzIHRv
IHRoZSBoZWxwIG9mIEJlbm9pdCBEZXNqYXJkaW5zDQooaHR0cDovL3d3dy5yYWQubWVkLnVt
aWNoLmVkdS9wZW9wbGUvZGVmYXVsdC5hc3A/VXNlcklEPTY4MCksIHZtdGsgDQpub3cgY29t
cGlsZXMgdW5kZXIgV2luZG93cyAodGVzdGVkIHdpdGggTSQgVkMrKyA2LjApLg0KQSBiaW5h
cnkgV2luZG93cyB2ZXJzaW9uIHNob3VsZCBmb2xsb3cgaW4gdGhlIG5leHQgbW9udGhzLg0K
IEkgZW5jb3VyYWdlIGV2ZXJ5b25lIHRvIHVwZ3JhZGUgdG8gdGhpcyBuZXcgdmVyc2lvbi4g
QmFja3dhcmRzDQpjb21wYXRpYmlsaXR5IHdpdGggdm10ayAwLjQgKGluIHRlcm1zIG9mIFB5
cGVzIHRoYXQgd2lsbCBhY3R1YWxseSB3b3JrIA0KbGlrZSBiZWZvcmUpIHdhcyBwcmVzZXJ2
ZWQgaW4gdGhlIGxhcmdlc3QgcGFydC4gVGhlIG9ubHkgZGlmZmVyZW5jZSBpcw0KaW4gYnZn
YnJhbmNoZXh0cmFjdG9yIGFuZCBidmdlbmRwb2ludGV4dHJhY3Rvciwgd2hpY2ggbm93IG9u
bHkgcGVyZm9ybSB0aGUNCnNwbGl0dGluZyBvbiB0aGUgY2VudGVybGluZXMsIGxlYXZpbmcg
dGhlIHN1cmZhY2UgY2xpcHBpbmcgdG8NCmJ2Z2JyYW5jaGNsaXBwZXIuIENvbnNlcXVlbnRs
eSwgdGhlIGZvcm1lciB0d28gc2NyaXB0cyBkbyBub3QgaGF2ZSB0aGUNCi1jbGlwc3VyZmFj
ZSBvcHRpb24gYW55bW9yZS4gVG8gcmVwcm9kdWNlIHRoZSBzYW1lIGJlaGF2aW9yLCBqdXN0
IHBpcGUNCmJ2Z2JyYW5jaGNsaXBwZXIgYWZ0ZXIgYnZnYnJhbmNoZXh0cmFjdG9yIG9yIGJ2
Z2VuZHBvaW50ZXh0cmFjdG9yLg0KIEEgZGVzaXJlZCBuZXcgZmVhdHVyZSBpcyB0aGUgcG9z
c2liaWxpdHkgb2YgaW50ZXJhY3RpdmVseSBjaG9vc2luZyB3aGljaA0KZmxvdyBleHRlbnNp
b25zIHRvIGdlbmVyYXRlLiBBbHNvLCBmbG93IGV4dGVuc2lvbnMgYXJlIG5vdyBzbW9vdGhs
eQ0KZ2VuZXJhdGVkIGZyb20gdGhlIG9wZW4gYm91bmRhcmllcyB0aGFua3MgdG8gdGhlIG5l
dyB0aGluIHBsYXRlIHNwbGl0ZQ0KaW50ZXJwb2xhdGlvbiBzY2hlbWUuIEFtb25nIHRoZSBu
b3ZlbHRpZXMsIGltdWNlbnRlcmxpbmV2aWV3ZXIgaXMgYSANCm5pY2Ugd2F5IG9mIHZpc3Vh
bGl6aW5nIEdyb3VwSWRzIChhbmQgc3VjaCkgb24gY2VudGVybGluZXMgb25jZSB5b3UndmUg
DQpzcGxpdCB0aGVtLCBhbmQgYnZnY2VudGVybGluZWxhYmVsZXIgZ2l2ZXMgeW91IHRoZSBv
cHRpb24gb2YgbWFudWFsbHkgDQpjaGFuZ2luZyBHcm91cElkcyAoYW5kIHN1Y2gpIHRvIHBl
cmZvcm0gd2VpcmQgc3BsaXR0aW5nIGNvbWJpbmF0aW9ucyANCihsaWtlIGNob3BwaW5nIG9m
ZiBhbiB1bmRlc2lyZWQgYnJhbmNoKS4NCiBIYXZlIGZ1biB3aXRoIHZtdGssIGFuZCBwbGVh
c2UgcG9zdCBhbnkgcXVlc3Rpb25zIG9uIHRoaXMgbGlzdC4NCg0KTHVjYQ0KIA0KDQotLSAN
Ckx1Y2EgQW50aWdhLCBQaEQNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0NCkJpb21lZGljYWwgVGVjaG5vbG9naWVzIExhYm9yYXRvcnkNCkJpb2Vu
Z2luZWVyaW5nIERlcGFydG1lbnQsIA0KTWFyaW8gTmVncmkgSW5zdGl0dXRlDQpWaWxsYSBD
YW1venppLCAyNDAyMCwgUmFuaWNhIChCRyksIEl0YWx5DQotLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpwaG9uZTogKzM5IDAzNSA0NTM1LTM4MQ0K
ZW1haWw6IGFudGlnYUBtYXJpb25lZ3JpLml0DQp3ZWI6ICAgaHR0cDovL3ZpbGxhY2Ftb3p6
aS5tYXJpb25lZ3JpLml0L35sdWNhDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkRlc3Rp
bmEgaWwgdHVvIDUgcGVyIG1pbGxlIGRlbGwnSVJQRUYgKHN1bCBtb2QuIDczMCBvIG1vZC4g
VU5JQ08NClBGIG8gbW9kLiBDVUQpIGNvbiB1bmEgIGZpcm1hIGluZGljYW5kbyBpbCBub3N0
cm8gY29kaWNlIGZpc2NhbGUNCjAzMjU0MjEwMTUwICBwZXIgIGFpdXRhcmUgIGEgbWFudGVu
ZXJlIGluZGlwZW5kZW50ZSAgbGEgIHJpY2VyY2ENCnNjaWVudGlmaWNhICBkZWxsJ0lzdGl0
dXRvICBNYXJpbyBOZWdyaSwgdW5hICBmb25kYXppb25lIHByaXZhdGENCnNlbnphIHNjb3Bv
IGRpIGx1Y3JvIGNoZSBkYSBvbHRyZSA0MCBhbm5pICBvcGVyYSAgbmVsbCdpbnRlcmVzc2UN
CmRlZ2xpIGFtbWFsYXRpLg0KDQpQZXIgbWFnZ2lvcmkgaW5mb3JtYXppb25pOg0KSXN0aXR1
dG8gTWFyaW8gTmVncmksIFZpYSBFcml0cmVhIDYyIC0gMjAxNTcgTWlsYW5vDQpUZWw6ICsz
OSAwMiAzOTAxNDMxNyAtIEZheDogKzM5IDAyIDM1NDYyNzcgKzM5IDAyIDM5MDAxOTE4DQpJ
bnRlcm5ldDogd3d3Lm1hcmlvbmVncmkuaXQsIG1uZWdyaUBtYXJpb25lZ3JpLml0

Re: [vmtk-users] Flow Extensions

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

SGV5IFRpemlhbm8sIA0KIHdlbGwgZG9uZSBwb3N0aW5nIG9uIHRoZSBtYWlsaW5nIGxpc3Qh
IExldCdzIHNlZSBpZiB3ZSBnZXQgcGVvcGxlDQp1c2VkIHRvIGl0IG9yIGp1c3QgbWFrZSBv
dXIgbGlmZSBtb3JlIGNvbXBsaWNhdGVkLi4uDQogVGhlcmUgYXJlIGJhc2ljYWxseSB0d28g
d2F5cyBvZiBzcGVjaWZ5aW5nIHRoZSBsZW5ndGggb2YgZmxvdyBleHRlbnNpb25zOg0Kb25l
IGlzIHRocm91Z2ggLWV4dGVuc2lvbmxlbmd0aCBMLCB3aGVyZSBMIGlzIHRoZSBhYnNvbHV0
ZSBsZW5ndGggb2YNCnRoZSBmbG93IGV4dGVuc2lvbi4gDQogSW4gY2FzZSB5b3Ugc3BlY2lm
eSAtYWRhcHRpdmVsZW5ndGggMSwgLWV4dGVuc2lvbmxlbmd0aCBpcyBpZ25vcmVkLA0KYW5k
IGxlbmd0aCBpcyBzcGVjaWZpZWQgdGhyb3VnaCAtZXh0ZW5zaW9ucmF0aW8gUiBhcyANCiJS
ICogc2VjdGlvbl9yYWRpdXMiLCBhcyB5b3UgYWxyZWFkeSBmb3VuZCBvdXQgKG5vdGUgdGhh
dCBSIGlzIG5vdA0KbmVjZXNzYXJ5IGFuIGludCkuDQogSW4gdGhlIG5leHQgcmVsZWFzZSwg
d2hpY2ggd2lsbCBjb21lIG91dCBzaG9ydGx5LCBidmdmbG93ZXh0ZW5zaW9ucw0Kd2lsbCBi
eSBkZWZhdWx0IGFzayB3aGljaCBleHRlbnNpb25zIGhhdmUgdG8gYmUgZ2VuZXJhdGVkDQpp
bnRlcmFjdGl2ZWx5LCBzbyBpZiB5b3UgcnVuIGl0IG1vcmUgdGhhbiBvbmNlLCB5b3UgY2Fu
IHByb2R1Y2UNCmV4dGVuc2lvbnMgd2l0aCBkaWZmZXJlbnQgbGVuZ3Rocy4NCiBJZGVhbGx5
IEkgd291bGQgbGlrZSB0byByZWxlYXNlIGJlZm9yZSBXQ0IgaW4gTXVuaWNoIChpLmUuIGJl
Zm9yZSB0aGUgd2Vla2VuZCkuLi4NCkNpYW8hDQoNCkx1Y2ENCg0KDQoNCk9uIFdlZCwgSnVs
IDI2LCAyMDA2IGF0IDAzOjUzOjE5UE0gKzAyMDAsIFRpemlhbm8gUGFzc2VyaW5pIHdyb3Rl
Og0KPiBIZWxsbyBldmVyeWJvZHksDQo+IA0KPiB3aGVuIHJ1bm5pbmcgdGhlIHB5cGUgDQo+
IA0KPiBbLi4uXSAtLXB5cGUgYnZnZmxvd2V4dGVuc2lvbnMgLWV4dGVuc2lvbnJhdGlvIE4N
Cj4gDQo+IChnaXZlbiBhbiBvcGVuIHN1cmZhY2UgYW5kIGNlbnRlcmxpbmVzIGV2YWx1YXRl
ZCBpbiBpdCksIHdoYXQgZG9lcw0KPiBleGFjdGx5ICJOIiBzdGFuZCBmb3I/DQo+IA0KPiBG
b3Igd2hhdCBJIGNhbiBzZWUsIEkgd2lsbCBvYnRhaW4gZmxvdyBleHRlbnNpb25zICJOICog
c2VjdGlvbl9yYWRpdXMiDQo+IGxvbmcuIEFtIEkgY29ycmVjdD8NCj4gDQo+IElmIG5vdCwg
aXMgdGhlcmUgYSB3YXkgdG8gZXZhbHVhdGUgdGhlIGxlbmd0aCBvZiBlYWNoIGZsb3cgZXh0
ZW5zaW9uPw0KPiANCj4gVGhhbmtzIGluIGFkdmFuY2UNCj4gDQo+IFRpemlhbm8gUGFzc2Vy
aW5pDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBUYWtlIFN1cnZleXMuIEVh
cm4gQ2FzaC4gSW5mbHVlbmNlIHRoZSBGdXR1cmUgb2YgSVQNCj4gSm9pbiBTb3VyY2VGb3Jn
ZS5uZXQncyBUZWNoc2F5IHBhbmVsIGFuZCB5b3UnbGwgZ2V0IHRoZSBjaGFuY2UgdG8gc2hh
cmUgeW91cg0KPiBvcGluaW9ucyBvbiBJVCAmIGJ1c2luZXNzIHRvcGljcyB0aHJvdWdoIGJy
aWVmIHN1cnZleXMgLS0gYW5kIGVhcm4gY2FzaA0KPiBodHRwOi8vd3d3LnRlY2hzYXkuY29t
L2RlZmF1bHQucGhwP3BhZ2U9am9pbi5waHAmcD1zb3VyY2Vmb3JnZSZDSUQ9REVWREVWDQo+
IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHZt
dGstdXNlcnMgbWFpbGluZyBsaXN0DQo+IHZtdGstdXNlcnNAbGlzdHMuc291cmNlZm9yZ2Uu
bmV0DQo+IGh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL3Zt
dGstdXNlcnMNCg0KLS0gDQpMdWNhIEFudGlnYSwgUGhEDQotLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpCaW9tZWRpY2FsIFRlY2hub2xvZ2llcyBM
YWJvcmF0b3J5DQpCaW9lbmdpbmVlcmluZyBEZXBhcnRtZW50LCANCk1hcmlvIE5lZ3JpIElu
c3RpdHV0ZQ0KVmlsbGEgQ2Ftb3p6aSwgMjQwMjAsIFJhbmljYSAoQkcpLCBJdGFseQ0KLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KcGhvbmU6ICsz
OSAwMzUgNDUzNS0zODENCmVtYWlsOiBhbnRpZ2FAbWFyaW9uZWdyaS5pdA0Kd2ViOiAgIGh0
dHA6Ly92aWxsYWNhbW96emkubWFyaW9uZWdyaS5pdC9+bHVjYQ0KLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg0KDQotLS0tLS0tLS0tLS0t
LS0tLS0tLS0tDQpEZXN0aW5hIGlsIHR1byA1IHBlciBtaWxsZSBkZWxsJ0lSUEVGIChzdWwg
bW9kLiA3MzAgbyBtb2QuIFVOSUNPDQpQRiBvIG1vZC4gQ1VEKSBjb24gdW5hICBmaXJtYSBp
bmRpY2FuZG8gaWwgbm9zdHJvIGNvZGljZSBmaXNjYWxlDQowMzI1NDIxMDE1MCAgcGVyICBh
aXV0YXJlICBhIG1hbnRlbmVyZSBpbmRpcGVuZGVudGUgIGxhICByaWNlcmNhDQpzY2llbnRp
ZmljYSAgZGVsbCdJc3RpdHV0byAgTWFyaW8gTmVncmksIHVuYSAgZm9uZGF6aW9uZSBwcml2
YXRhDQpzZW56YSBzY29wbyBkaSBsdWNybyBjaGUgZGEgb2x0cmUgNDAgYW5uaSAgb3BlcmEg
IG5lbGwnaW50ZXJlc3NlDQpkZWdsaSBhbW1hbGF0aS4NCg0KUGVyIG1hZ2dpb3JpIGluZm9y
bWF6aW9uaToNCklzdGl0dXRvIE1hcmlvIE5lZ3JpLCBWaWEgRXJpdHJlYSA2MiAtIDIwMTU3
IE1pbGFubw0KVGVsOiArMzkgMDIgMzkwMTQzMTcgLSBGYXg6ICszOSAwMiAzNTQ2Mjc3ICsz
OSAwMiAzOTAwMTkxOA0KSW50ZXJuZXQ6IHd3dy5tYXJpb25lZ3JpLml0LCBtbmVncmlAbWFy
aW9uZWdyaS5pdA==

[vmtk-users] Flow Extensions

[Tiziano P. <tiz...@ma...>]

Hello everybody,

when running the pype 

[...] --pype bvgflowextensions -extensionratio N

(given an open surface and centerlines evaluated in it), what does
exactly "N" stand for?

For what I can see, I will obtain flow extensions "N * section_radius"
long. Am I correct?

If not, is there a way to evaluate the length of each flow extension?

Thanks in advance

Tiziano Passerini

[vmtk-users] Flow Extensions

[Tiziano P. <tiz...@ma...>]

Hello everybody,

when running the pype 

[...] --pype bvgflowextensions -extensionratio N

(given an open surface and centerlines evaluated in it), what does
exactly "N" stand for?

For what I can see, I will obtain flow extensions "N * section_radius"
long. Am I correct?

If not, is there a way to evaluate the length of each flow extension?

Thanks in advance

Tiziano Passerini

RE: [vmtk-users] Feedback from users

[Yannis P. <ya...@ia...>]

Dear Luca,

Please find answers to your questions below. Further feedback will be
generated as I apply vmtk in more tasks. 

Yannis

-----Original Message-----
From: vmt...@li...
[mailto:vmt...@li...] On Behalf Of
an...@ma...
Sent: Monday, May 16, 2005 11:13 AM
To: vmt...@li...
Subject: [vmtk-users] Feedback from users

Dear vmtk-users,
 thanks for your interest in this project. 
Although still work in progress, vmtk is used by several people 
in our labs on a daily basis. 
I'd like to have a feedback from the outer world as well.
I'd appreciate if you took a few minutes to briefly sketch 
the following information:

- did you use vmtk in your actual work or did you just give it a try? 

I did use vmtk in my work with very good results. 

- are you still using it or do you plan to use it in the future?

I am still using vmtk and I do plan to use in the future.

- if not, what are the main reasons?

- what's the major limitation you see in vmtk now?

The lack of detailed documentation.

- what would you like to see in vmtk in the future?

Better documentation. 


Thanks for your time, I'm counting on you for further feedback,
contributions and advertising...

Luca


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



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
vmtk-users mailing list
vmt...@li...
https://lists.sourceforge.net/lists/listinfo/vmtk-users

[vmtk-users] Feedback from users

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

Dear vmtk-users,
 thanks for your interest in this project. 
Although still work in progress, vmtk is used by several people 
in our labs on a daily basis. 
I'd like to have a feedback from the outer world as well.
I'd appreciate if you took a few minutes to briefly sketch 
the following information:

- did you use vmtk in your actual work or did you just give it a try? 

- are you still using it or do you plan to use it in the future?

- if not, what are the main reasons?

- what's the major limitation you see in vmtk now?

- what would you like to see in vmtk in the future?

Thanks for your time, I'm counting on you for further feedback,
contributions and advertising...

Luca


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