[Insight-users] Performance of 3D Watershed?

[Joshua Cates]

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
>