Posted by
Michael Schmid on
Mar 25, 2011; 3:19pm
URL: http://imagej.273.s1.nabble.com/Watershed-Algorithm-source-bug-tp3685192p3685195.html
Hi Gabriel, Dave,
oh, sorry I only had a look at the sample image of the Watershed
plugin, which is binary, I did not read all of the text (and I had
never used that plugin)
Watershed segmentation of a grayscale image is in "Find Maxima", with
output type='Segmented Particles'. The maxima are taken as seeds (use
preview to determine the 'tolerance', i.e., the sensitivity desired).
It should be reasonably fast.
One restriction: I think that in some rather unusual geometries it
may draw dividing lines between areas belonging to one maximum (one
'basin' in watershed terminology)
Michael
________________________________________________________________
On 25 Mar 2011, at 13:36, Gabriel Landini wrote:
> On Friday 25 Mar 2011 09:58:00 you wrote:
>> a side note:
>> There is also an alternative to this plugin using Built-in ImageJ
>> commands:
>> Process>Binary>Watershed, then Process>Binary>Voronoi, and
>> thresholding the result at 1-255
>
> Just being picky :-)
> The watershed command in ImageJ is not strictly the watershed we
> are talking
> about, it is "watershed separation". Watershed is a greyscale
> operation, not
> binary...
>
> It is useful to perform watersheds on greyscale images with "markers".
> Markers (derived from the greyscale image) are used to avoid
> oversegmentation.
> "Impose minima" (which depends of greyscale reconstruction) and
> "extended
> regional minima" can be used for marking the images, so no false
> basins are
> detected.
>
> Going back to the original subject, I tried the suggested fix and
> indeed it
> makes some dam lines thinner, but I do not think this algorithm is
> correct
> anyway. Strangely there is a comment in the source code that this
> is the
> original method, why was the <= added is a mystery to me.
>
> But anyway, a major problem I see is that there are too many
> horizontal lines.
> If you rotate the original image 90 degrees and apply the
> watershed, the
> result is nowhere near to the un-rotated one. Of course I accept
> that there
> might be tiny differences because of the sequential way that the
> image is
> processed, but the observed results cannot be correct.
>
> Daniel Sage's watershed is I think correct, but unfortunately it is
> slow on
> large images and very few times I get some strange patterns (like
> pixels
> isolated inside another basin which should not be there).
>
> Cheers
>
> Gabriel