[Insight-users] Inconsistent watershed behaviour?

[Atwood, Robert C]

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;



        
-------------- next part --------------
A non-text attachment was scrubbed...
Name: slice005_l008_t003_noloop_testreg.mhd.png
Type: image/png
Size: 4385 bytes
Desc: slice005_l008_t003_noloop_testreg.mhd.png
Url : http://public.kitware.com/pipermail/insight-users/attachments/20040813/52a8285c/slice005_l008_t003_noloop_testreg.mhd-0001.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: slice005_l008_t003_loop_testreg.mhd.png
Type: image/png
Size: 3686 bytes
Desc: slice005_l008_t003_loop_testreg.mhd.png
Url : http://public.kitware.com/pipermail/insight-users/attachments/20040813/52a8285c/slice005_l008_t003_loop_testreg.mhd-0001.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itk_wshd_rca.tgz
Type: application/x-compressed
Size: 7138 bytes
Desc: itk_wshd_rca.tgz
Url : http://public.kitware.com/pipermail/insight-users/attachments/20040813/52a8285c/itk_wshd_rca-0001.bin