Watershed Algorithm source - bug

[David Pont]

I recently found source code for the Watershed Algorithm Plugin for ImageJ at the RSB web site

For the record -
After a google search I found a link to the source on a Wikipedia page:

http://en.wikipedia.org/wiki/Watershed_%28image_processing%29

which linked to a page hosted at the RSB web site here:
http://rsbweb.nih.gov/ij/plugins/watershed.html

I ported the code to Python and carried out some tests by processing the same input image through ImageJ and my code. I found a bug which caused incorrect location of watershed boundaries.
The bug appears in the original Java code I obtained from the RSB site. It seems likely that it has been found and fixed earlier, as it does not manifest in ImageJ. I suppose the code I got from the RSB site is out of date with respect to the current code for the Watershed Algorithm plugin in ImageJ.

The bug is fixed by changing line 160 in Watershed_Algorithm.java
from:
                                    if( (q.getDistance() <= curdist) &&
to:
                                    if( (q.getDistance() < curdist) &&


regards, Dave



________________________________


This e-mail and any attachments may contain information which is confidential or subject to copyright. If you receive this e-mail in error, please delete it.
Scion does not accept responsibility for anything in this e-mail which is not provided in the course of Scion's usual business or for any computer virus, data corruption, interference or delay arising from this e-mail.

[Michael Schmid]

Hi Dave,

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

There will be subtle differences, however: Any Watershed segmentation  
of data given at discrete pixels needs some fine tuning to avoid  
oversegmentation. So you have to see which algorithm is better for  
your needs.

Michael
________________________________________________________________

On 24 Mar 2011, at 23:16, David Pont wrote:

> I recently found source code for the Watershed Algorithm Plugin for  
> ImageJ at the RSB web site
>
> For the record -
> After a google search I found a link to the source on a Wikipedia  
> page:
>
> http://en.wikipedia.org/wiki/Watershed_%28image_processing%29
>
> which linked to a page hosted at the RSB web site here:
> http://rsbweb.nih.gov/ij/plugins/watershed.html
>
> I ported the code to Python and carried out some tests by  
> processing the same input image through ImageJ and my code. I found  
> a bug which caused incorrect location of watershed boundaries.
> The bug appears in the original Java code I obtained from the RSB  
> site. It seems likely that it has been found and fixed earlier, as  
> it does not manifest in ImageJ. I suppose the code I got from the  
> RSB site is out of date with respect to the current code for the  
> Watershed Algorithm plugin in ImageJ.
>
> The bug is fixed by changing line 160 in Watershed_Algorithm.java
> from:
>                                     if( (q.getDistance() <=  
> curdist) &&
> to:
>                                     if( (q.getDistance() < curdist) &&
>
>
> regards, Dave
>

[Gabriel Landini]

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

[Michael Schmid]

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

[Posthume]

Hi Gabriel,

I'm currently working on the Watershed plugin and i noticed as well that when i rotate the original image 90 degrees and apply the watershed, i get a very different result. Could you solve in some way that bug or do you use any other alternatives to that plugin?

Thank you in advance for your reply.

Michael.

[Nathaniel Ryckman]

If you are able to make something that is effective, please keep us updated :-)!

I also was interested in Daniel Sage's program, but the program took way too long to run. In addition, I have a very amorphous cell set to work with (macrophages from drosophila that are often clumped and always unevenly stained), and his program wasn't precise enough for use.

Even on the demo picture on the page, the software doesn't do a good enough job of segmentation:
http://bigwww.epfl.ch/sage/soft/watershed/

I created a large macro that uses the grayscale image to segment nuclei. The program currently works excellently. The only glaring problem is that the program will obtain ROI's that are too small when the blobs are heavily clumped and have very similar areas of high intensity pixels touching each other.

Unfortunately, I think that I too will have to resort to editing the watershed program since the macro language doesn't offer enough control as far as I am aware of.

[Cammer, Michael]

Would it be possible to please include in the .nd2 opener an option to open the frames in the order they are saved with assurance that their gray values will be preserved properly?  This way even if we need to write a quick macro to reorder the images, at least we will have access to the gray values.

The problem is that now when we have files with multi-channel tiled time-lapses, the files are sorted into the correct order, but the gray values are interleaved oddly.  I've been getting around this by keeping past versions of the plugins that work for different specific files types on my computer, but it would be good to have one no-frills stable configuration that does not change, like for any file type the option to open the pictures strictly in the order they were saved with preservation of the pixel values.

Thank you.

Regards,

Michael

------------------------------------------------------------
This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is proprietary, confidential, and exempt from disclosure under applicable law. Any unauthorized review, use, disclosure, or distribution is prohibited. If you have received this email in error please notify the sender by return email and delete the original message. Please note, the recipient should check this email and any attachments for the presence of viruses. The organization accepts no liability for any damage caused by any virus transmitted by this email.
=================================