[slicer-users] VMTK centerlines and failure to allocate memory

Madan Rao rao.lms at gmail.com
Mon Jun 14 22:33:56 EDT 2010


Hello all,

I just started a pilot study on VMTK Slicer module and segmentations and I
ran into the same problem.

I use 3GB RAM windows vista. As this memory is insufficient for most of the
time I found a workaround by:

(a). I extract RCA and LCA separately from two different VOIs. (b). Since
LCA is more complex, one can run

into memory problems during centerline extractions. In such a case I extract
LCA module from blood pool

using editor and mask image modules (as suggested sometime ago by Ron in
this forum). (c). One can adjust

the display to evolve only the main branch structures of arteries to limit
the leakage from unimportant thin

branches.


hope this helps.

regards.

AM Mohan Rao


On Tue, Jun 15, 2010 at 1:29 AM, Luca Antiga <luca.antiga at gmail.com> wrote:

> Hey,
>  just a quick addition on the issue of narrow vessels.
> Increasing the density of surface triangles using a Loop or Butterfly
> subdivision filter (both of which are in VTK) can also help, although
> it will increase the computing time considerably.
> Needless to say, these are workarounds. The long-term fix would be to
> handle the degeneracies of the underlying Voronoi diagram. I'll take
> this into account for future developments.
> Best regards
>
> Luca
>
>
>
> On Jun 14, 2010, at 8:32 PM, Daniel Haehn wrote:
>
> > Hi curt,
> >
> > Exactly. Smoothing the surface should help f.e. with a taubin non-
> > shrinking filter. A little bit of smoothing takes place during the
> > preparation stage of the VMTKCenterlines module but it might not be
> > enough in this case. I will add the option to specify the smoothing
> > rate manually.
> >
> > Bye,
> > Daniel
> >
> > Curtis Lisle <curtislisle at knowledgevis.com> wrote:
> >
> >> Sometimes surfaces that are very regular create problems for the
> >> center line algorithm in VMTK.  It might be, in this case, that the
> >> geometry and the surfaces are regular enough that the Fast Marching
> >> part of the  centerline algorithm gets stuck.   I would suggest
> >> smoothing the surface created from the image just a bit before
> >> computing center lines.  This will perturb the surface vertices
> >> just a bit.    We had a similar situation once when using the VMTK
> >> commandline tools, and our solution was to perturb the surface
> >> before trying to compute center lines.
> >>
> >> I haven't used the VMTK Slicer module much, but maybe this
> >> experience with the commandline version of VMTK will help.  Take
> >> care!
> >>
> >> Curt
> >>
> >>
> >>
> >> On Jun 14, 2010, at 2:06 PM, Daniel Haehn wrote:
> >>
> >>> Hi julie,
> >>>
> >>> I experienced out of memory errors when the input surface is very
> >>> narrow at some points (f.e. due to stenosis). Maybe you can try to
> >>> set the start and end fiducials closer together to try if it works
> >>> at all on the model. If you would like to send me the segmented
> >>> surface model, I would be happy to take a look.
> >>>
> >>> Thank you for using VMTK in 3D Slicer.
> >>>
> >>> Daniel
> >>>
> >>> Julie Rytlewski <j.rytlewski at gmail.com> wrote:
> >>>
> >>>>
> >>>> Hello,
> >>>>
> >>>> I've been unable to successfully run the VMTK centerlines module
> >>>> on my
> >>>> image stack--it stops about 40min to an hour into processing with a
> >>>> "failure to locate [large number] of bytes." The data consists of
> >>>> 300
> >>>> confocal microscopy images (Z-stack), approximately isotropic,
> >>>> 1024x1024
> >>>> resolution, 8-bit grayscale. I've tried down-sampling to 512x512--
> >>>> that
> >>>> didn't work. I tried taking an ROI from the 512x512 stack with the
> >>>> volume cropping module--still didn't work. I've tried down-
> >>>> sampling the
> >>>> ROI to somewhere near 256x256--nadda. I've tried deleting all
> >>>> previous
> >>>> volumes and loading only the ones necessary for centerlines and
> >>>> that
> >>>> didn't help. The vessel enhancement and level sets modules run just
> >>>> fine. I'm running this on an iMac with 8GB of RAM.
> >>>>
> >>>> Are there other options to conserve memory? Or does this module
> >>>> have a
> >>>> leak? I'm not convinced that this module is maxing out 8GB of
> >>>> memory...
> >>>> or maybe it's not allocating enough to finish processing the data??
> >>>>
> >>>> Any help or advice would be very much appreciated.
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Julie
> >>>>
> >>>> _______________________________________________
> >>>> slicer-users mailing list
> >>>> slicer-users at bwh.harvard.edu
> >>>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
> >>>> To unsubscribe: send email to
> slicer-users-request at massmail.spl.harvard.edu
> >>>>  with unsubscribe as the subject
> >>> _______________________________________________
> >>> slicer-users mailing list
> >>> slicer-users at bwh.harvard.edu
> >>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
> >>> To unsubscribe: send email to
> slicer-users-request at massmail.spl.harvard.edu
> >>>  with unsubscribe as the subject
> >>
> > _______________________________________________
> > slicer-users mailing list
> > slicer-users at bwh.harvard.edu
> > http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
> > To unsubscribe: send email to
> slicer-users-request at massmail.spl.harvard.edu
> >  with unsubscribe as the subject
>
> _______________________________________________
> slicer-users mailing list
> slicer-users at bwh.harvard.edu
> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
> To unsubscribe: send email to
> slicer-users-request at massmail.spl.harvard.edu with unsubscribe as the
> subject
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://massmail.spl.harvard.edu/pipermail/slicer-users/attachments/20100615/1d052ba4/attachment.html>


More information about the slicer-users mailing list