[Insight-users] Performance of 3D Watershed?

[Harri Tapio Jaalinoja]

Hi Joshua,

thanks for your help! Right endianness did the trick.

I have yet to figure out how to visualize the structure (we use OpenDX),
but apart from fine tuning the filtering values, the segmentation
code seems to be in place. So easy?

Thanks,
Harri

On Tue, 22 Oct 2002, Joshua Cates wrote:

> Hi,
>
> My first guess as to what is happening is that you are processing a data
> set which contains too much detail for the algorithm to handle in a
> reasonable time frame.  The complexity of the watersheds algorithm is
> nonlinear, so too much detail in an image (regardless of image size) will
> cause executions times to blow up from seconds to hours.  (Have you
> checked the endianness of your data?  Reading in unsigned short data using
> the wrong byte order will give very noisy looking data.)
>
> Good preprocessing to remove noise and uninteresting detail is critical to
> getting a good result with the watersheds technique.  Consider more
> iterations of the GradientMagnitudeAnisotropicDiffusionImageFilter (10 is
> a good number to try, with conductance term 1.0).  Also, cropping the data
> to contain only the region you are interested in is helpful.  The
> watersheds algorithm operates on the entire image at once, so any areas of
> the image which are uninteresting are only going to slow down the process
> for you.
>
> That said, I'm surprised that the algorithm is bogging down without using
> up more of your memory.  Is the amount of free memory you show during
> processing?  I have run the watersheds algorithm on MRI volumes larger
> than your data (256x256x123) by smoothing first with
> GradientAnisotropicDiffusionImageFilter 10x 1.0 conductance.  After
> extracting edge features, the watersheds finishes in roughly 30 seconds.
>
> Hope this helps,
>
> Josh.
>
> ______________________________
>  Josh Cates
>  School of Computer Science
>  University of Utah
>  Email: cates@sci.utah.edu
>  Phone: (801) 587-7697
>  URL:   www.cs.utk.edu/~cates
>
>
> On Tue, 22 Oct 2002, Harri Tapio Jaalinoja wrote:
>
> >
> > Hi!
> >
> > I am running code based on the watershed example to segment a 101^3 cube
> > of electron microscopy density data (type = short).
> >
> > The problem is that the code seems to stall my machine.
> > The progress command meter writes first 3 dots almost right away, the 4th
> > after a while, but the 5th I never saw.
> >
> > I am not using the gradient magnitude image filter because the density
> > values as such should be a valid height function.
> >
> > I don't have a smaller data cube at the moment I could experiment with.
> > I can simply read data from the existing file, to fill in a smaller cube.
> > This of course messes up the structure, but might give some idea about the
> > processing. A cube of 33^3 already stalls the machine, 32^3 is processed
> > fairly quickly.
> >
> > My processor:
> > model name      : AMD Athlon(TM) XP2200+
> > stepping        : 0
> > cpu MHz         : 1800.110
> >
> > Available memory:
> > [hajaalin@gene work]$ free -m
> >              total       used       free     shared    buffers     cached
> > Mem:          1008        170        837          0         15         77
> > -/+ buffers/cache:         77        931
> > Swap:          243         11        231
> >
> > I am running Mandrake Linux 9.0.
> >
> > Here's some info about the data
> > Number of images:               1
> > Dimensions:                     101 101 101 voxels
> > Page dimensions:                101 101 101 voxels
> > Channels:                       1
> > Data type:                      short (size = 2)
> > Color model:                    Gray scale
> > Voxel units/sampling:           8.89903 8.89903 8.89903 A/voxel
> > Min, max, ave, std:             -1813.35 2149.04 11.9238 0
> >
> > I have tried various values for the anisotropic diffusion filter. At all
> > values a cube size can be found that is no longer processed (at least
> > nowhere as quickly as the one step smaller cube). The biggest cube (32^3)
> > was in fact processed without the filter.
> >
> > With some values I get this:
> > ..........Exception caught during processing.
> > Unknown
> > itk::ERROR: itk::watershed::SegmentTreeGenerator::MergeSegments:: An
> > unexpected and fatal error has occurred. This is probably the result of
> > overthresholding of the input image.
> >
> > which at least clearly tells that something is going wrong.
> >
> > Based on your experience, what do you make of the numbers and ramblings
> > above? Any ideas I could experiment with?
> >
> > Thanks for your help!
> >
> > Harri
> >
> > _______________________________________________
> > Insight-users mailing list
> > Insight-users@public.kitware.com
> > http://public.kitware.com/mailman/listinfo/insight-users
> >
>
>