<div dir="ltr"><font><font face="verdana,sans-serif">I also suspected that at first, but the deviations are a lot bigger than what can be explained by discretization. Also, this should not be that much a problem for float images, but problem appears there as well. Most importantly of all, detected watershed lines do not lie where visual inspection expects them to be. One one slice I examined, the watershed line was shifted about 10 voxels!</font></font></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 13, 2013 at 6:35 PM, Richard Beare <span dir="ltr"><<a href="mailto:richard.beare@gmail.com" target="_blank">richard.beare@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'll attempt to check this out over the next couple of days.<br>
<br>
I suspect that you have run into issues with discrete nature of<br>
images, rather than a bug as such. Suppose that you are applying a<br>
watershed to a flat control surface. If the seed points are an odd<br>
number of voxels apart, and you chose the algorithm marking the<br>
watershed line, then the split will appear nicely down the middle. If<br>
you don't chose to mark the line then there will be a probably random<br>
choice of which voxels along the midpoint get assigned to which<br>
region. Conversely, if the seeds are an even number of voxels apart<br>
and you chose to mark the watershed line, then the line should lie<br>
between the pixels, but it can't. Hence it is likely to be jaggedly<br>
jumping between the two sides of the plateau. Similar things can<br>
happen with distance map control functions, as adjacent voxels can be<br>
equidistant from seeds, producing a plateau.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Thu, Feb 14, 2013 at 9:13 AM, Dženan Zukić <<a href="mailto:dzenanz@gmail.com">dzenanz@gmail.com</a>> wrote:<br>
> I think I have discovered a bug in WatershedImageFilter. Below is MWE which<br>
> reproduces the problem. Input, output and expected image attached.<br>
><br>
> The problem is that watershed lines are wrongly placed and rough (see<br>
> attached error highlights). I first discovered it while working with 3D<br>
> images, where the problem is more pronounced. I can also supply 3D float<br>
> images (1.3MB). MorphologicalWatershedFromMarkersImageFilter suffers from<br>
> the same problem.<br>
><br>
> #include <itkImageFileReader.h><br>
> #include <itkImageFileWriter.h><br>
> #include <itkWatershedImageFilter.h><br>
> #include <itkCastImageFilter.h><br>
><br>
> typedef itk::Image<unsigned char, 2> VisualizingImageType;<br>
><br>
> void main()<br>
> {<br>
> typedef itk::ImageFileReader<VisualizingImageType> rType;<br>
> rType::Pointer reader=rType::New();<br>
> reader->SetFileName("image2D.png");<br>
> reader->Update();<br>
> VisualizingImageType::Pointer dm=reader->GetOutput();<br>
> typedef itk::WatershedImageFilter<VisualizingImageType> wsType;<br>
> wsType::Pointer ws2=wsType::New();<br>
> ws2->SetThreshold(0);<br>
> ws2->SetLevel(0);<br>
> ws2->SetInput(dm);<br>
> ws2->Update();<br>
> typedef itk::CastImageFilter<wsType::OutputImageType,<br>
> VisualizingImageType> castType;<br>
> castType::Pointer caster=castType::New();<br>
> caster->SetInput(ws2->GetOutput());<br>
> caster->Update();<br>
> typedef itk::ImageFileWriter<VisualizingImageType> wType;<br>
> wType::Pointer writer=wType::New();<br>
> writer->SetFileName("imageWSint.png");<br>
> writer->SetInput(caster->GetOutput());<br>
> writer->Update();<br>
> }<br>
</div></div></blockquote></div><br></div>