[Insight-users] Inconsistent watershed behaviour?
Atwood, Robert C
r.atwood at imperial.ac.uk
Tue Sep 7 13:20:07 EDT 2004
What is the status of the watershed problem I mentioned before, should I
create a 'bug report' on the web site?
-Robert
-----Original Message-----
From: Miller, James V (Research) [mailto:millerjv at crd.ge.com]
Sent: 13 August 2004 19:33
To: Atwood, Robert C; Miller, James V (Research)
Cc: insight-users at itk.org
Subject: RE: [Insight-users] Inconsistent watershed behaviour?
Robert,
Thanks for running the test cases. This sounds like a bug.
Is the smaller volume of that you are running on something that you
can share? Otherwise, I'll try to find an image that exhibits the
same problem.
Some further questions to help narrow the search. What OS are running
on? Does it have more than one processor?
The "narrow artifacts" that appear in the image that does not work is
similar to some of the segmentation problems I have had with the
watershed.
Jim
-----Original Message-----
From: Atwood, Robert C [mailto:r.atwood at imperial.ac.uk]
Sent: Friday, August 13, 2004 2:20 PM
To: Miller, James V (Research)
Cc: insight-users at itk.org
Subject: RE: [Insight-users] Inconsistent watershed behaviour?
I had the same thought about subvolme versus whole volume, so I located
a feature that exhibited the behaviour, cropped a separate file from the
input around that location, then tried it on that. Those are the results
I posted. Of course when doing the real work I will have to deal with
the differences, but using a subvolume should help get close to the
useful parameters.
I did observe that a smaller section of the subvolume (in x- and y-
direction) than the one I finally chose would not give similar results,
due to a chain of bubbles going from one side to the other of the
domain, hence altering the geometry of the watersheds too much compared
to the larger volume.
Also I originally tried running one water level at 0.9 to start, outside
of the whole loop, then getting the region for input to the slicer from
this. I removed this in case it was causing the problem (as in the
#ifdef INITIAL section of the code) but without any change to the
observed behaviour.
I have tried your suggestion as follows:
Case A = setting the level at 1.0 first
Case B = not setting the level first.
Case B differs from Case A.
I created this in the same code by addign the CPP directive CASE_A and
removing the loop , and rebuilding the code with or without CASE_A
defined.
#ifdef CASE_A
/****************************/
level = 1.0;
watershed->SetLevel( level );
thresh = 0.09;
watershed->SetThreshold(thresh);
printf("setting watershed level %f\n",level);
fprintf(logfile,"setting watershed level %f\n",level);
try
{
watershed->Update();
}
catch( itk::ExceptionObject & exp )
{
std::cerr << "Exception caught 01 wshd !" << std::endl;
std::cerr << "Exiting !" << std::endl;
std::cerr << exp << std::endl;
exit(0);
/* exit, otherwise images get written anyways using the
wrong output */
/* causing erroneous conclusions! */
}
/********************************/
#endif /* CASE_A */
printf("Iteration %i %i : l=%f t=%f\n",i,j,level,thresh);
fprintf(logfile,"Iteration %i %i : l=%f
t=%f\n",i,j,level,thresh);
level=0.06;
thresh=0.09;
watershed->SetLevel( level );
watershed->SetThreshold(thresh);
try
{
watershed->Update();
}
catch( itk::ExceptionObject & exp )
{
std::cerr << "Exception caught 01 wshd !" << std::endl;
std::cerr << "Exiting !" << std::endl;
std::cerr << exp << std::endl;
exit(0);
/* exit, otherwise images get written anyways using the
wrong output */
/* causing erroneous conclusions! */
}
/* set up the slice writer */
...
-----Original Message-----
From: Miller, James V (Research) [mailto:millerjv at crd.ge.com]
Sent: 13 August 2004 18:18
To: Atwood, Robert C; insight-users at itk.org
Subject: RE: [Insight-users] Inconsistent watershed behaviour?
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;
More information about the Insight-users
mailing list