[Insight-users] Inconsistent watershed behaviour?

[Miller, James V (Research)]

I don't think I have seen this type of problem.  A few months ago, I fixed
some problems the watershed algorithm was having when the threshold was 
changed. 

However, I always run the Watershed algorithm by running at a high water
level and then running at a lower level.  I don't usually try to jump to 
a particular water level.  So maybe there is a problem.

A quick test may be to just run two executions:

watershed->SetLevel(level);
watershed->SetThreshold(threshold);
watershed->Update();
(write out the segmentation)

Then run

watershed->SetLevel(1.0);
watershed->SetThreshold(threshold);
watershed->Update();
watershed->SetLevel(level);
watershed->Update();
(write out the segmentation)

And see if these two segmentations are different.


(Now if you are comparing running watershed on a subvolume with a given set
of parameters with running waterhsed on the entire volume with a given set
of parameters, then I would expect different results.)

Jim



-----Original Message-----
From: Atwood, Robert C [mailto:r.atwood at imperial.ac.uk]
Sent: Friday, August 13, 2004 12:46 PM
To: insight-users at itk.org
Subject: [Insight-users] Inconsistent watershed behaviour?


Dear ITK List:

CVS version of ITK, Checked out today.

Cmake 2.0
Gnu/Linux OS  "Red Hat enterprise ws-3" (up2date) 



I have come up with the same Watershed problem I had a while ago; at
first I thought it was solved due to fixing an incorrect use of
try/catch in my code causing the watershed to abort when the memory got
full, but still printing the slice of the previous iteration --  but
here it is again.

If I apply the watershed repeatedly to the same volume input, altering
the level and threshold each time, I get different results than if I
apply a single level/threshold to the same volume. Since I have a large
volume to process, I am trying to guess a good parameter set by looking
at a subvolume and then applying to the whole volume .. but in this case
I am only talking about the subvolume alone. The algorithm works as
follows, (minimal pseudocode). A single iteration is obtained by setting
the highest and the lowest values equal (setting wloop and tloop to zero
in the input) so the code goes through exactly the same execution path
wheter or not looping is selected. The actual values used are printed to
a log file just as the SetThreshold and SetLevel methods are called. 

Is it possible that there is a problem with using watershed like this
rather than a bug in my code? I wish to run over several parameters
unattended, as the volume is large and interactive selection is too
slow. Also I don't have to write a GUI this way :-) 

However, the result from looping as far as parameters 8,3 gives a nice
result, but simply applying parameters 8,3 gives a bad result as seen in
the images attached. The pink blob near the middle is split up in the
non-looping case, as if the level were lower than that applied in the
looping case. The log file indicates that the values passed to SetLevel
and SetThrehsold are correct.

The minimum data that I have been able to reproduce on is gzipped to 120
Kb, I think it is too big to post to the list. I can email it to anyone
willing to look in detail but I hope that simply looking at the
pseudocode will reveal the problem ...

Thank you,

Robert



**************** Pseudo-code of the main algorithm:
get the data;
prefilter the volume;
calculate the highest and lowest level value from inputs; calculate the
higest and lowest threshold value;

loop by incrementing the threshold {
    watershed->SetThreshold( threshold );

    loop by decrementing the level{
       watershed->SetLevel( level );
       
       update the watershed (in try/catch), exit if caught;
      
       watershed output is fed to slice extractor, 
           which is fed to slice-colormapper, 
           which is fed to slicewriter;
      update the slicewriter (in try/catch);
    }
}
output the volume if required;