MaximumFinder algorithm reference

[Anònim Anònim]

Hi all,

I would like to know the theoretical background behind ImageJ's particle
segmenter, which can be found in MaximumFinder.java. There are plenty of
papers covering watershedding algorithms, but the code comments in
MaximumFinder never state which one they are using; I could not find the
answer among the mailing list discussions either. Any clue on the specific
paper that ImageJ's implementation is based on?

Thanks in advance!

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Michael Schmid]

Hi Anònim,

well, I don't know much about watershed papers, but I was working on the algorithm in ImageJ, just taking the algorithm in the previous source code as a starting point. It all dates back to the NIH Image version, written in Pascal by Wayne Rasband
  http://rsb.info.nih.gov/nih-image/download/source/Edm.p
There, see procedure DoWatershedSegmentation

Basically, it takes the result of "Find Maxima" as a seed, then dilates them. Dilation is restricted to avoid merging with another dilated area, without checking whether this other dilated area might actually belong to the same basin (it is not aware of topology, or, in other words, basins have no unique identifier). It simply checks the 8-neighborhood of a pixel that is a candidate to be set in dilation. If the already dilated pixels around it are non-contiguous, setting this pixel to the 'dilated' state is forbidden).
Details on the dilation algorithm: Dilation is always done on an 8-bit image, where dilation is done for each gray level separately: Each level has a tasklist, with all the pixels to process. The pixels in the tasklist are examined to find out whether they can be set by dilation in one of the 8 directions. This is done for all 8 directions; diagonal directions first; always a direction followed by the opposite one (i.e., first, all pixels are examined whether dilation in NW direction is possible, then the same in directions SE, NE, SW, N, S, E, W). For each level, this it is repeated until idempotence.

That's the algorithm I started with.

So, if anyone knows in what paper this algorithm is described, it would be welcome!


This algorithm works on images that are Euclidian distance maps (Process>Binary>Watershed), if each maximum is a seed. "Find Maxima" has a tolerance, so all local maxima that are below this tolerance are flattened first (the peaks are simply cut away, down to the level of the saddle point that connect it with a maximum that remains).

For image data that are not Euclidian Distance Maps, two modifications are necessary:
- Dilation may miss some areas at a given level. These must be kept on the tasklist for the next level that needs processing.
- The algorithm can result in lines that end in a single point. These do not separate basins (particles), so they are removed by post-processing.


Limitations of the algorithm:

- It is not gradient-aware. Separation lines do not run in exactly the correct direction. I did a few tries to implement a gradient method in the current algorithm, and it was kind of successful, but the code for it was so complicated that I decided I should not put it into ImageJ - in case of problems it would not be serviceable by anyone, including me :-)

- As noted above, basins have no identifier. Thus, a ring-like basin won't become a full ring in the segmentation but the ring will be split. In other words, the algorithm always results in simply connected areas.


Waiting for input by those who know the literature of watershed algorithms...

Michael
________________________________________________________________


On Nov 6, 2012, at 09:57, Anònim Anònim wrote:

> Hi all,
>
> I would like to know the theoretical background behind ImageJ's particle
> segmenter, which can be found in MaximumFinder.java. There are plenty of
> papers covering watershedding algorithms, but the code comments in
> MaximumFinder never state which one they are using; I could not find the
> answer among the mailing list discussions either. Any clue on the specific
> paper that ImageJ's implementation is based on?
>
> Thanks in advance!
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Stein Rørvik]

What Michael writes here is basically correct.

I did some work on this back in the mid-1990s, and used a modified algorithm in my own version of NIH image.
If I remember correctly, the algorithm used in both my and Wayne's implementation is basically the same as the one described on pages 153-161 in the 1992 book "Computer Assisted Microscopy" by John C. Russ. That chapter explains the principle of watershed segmentation very well. Using a "task list" of pixels for each level was my idea for speeding the algorithm up; I see I am credited for that in the old NIH image source code.

What I did additionally in my own implementation was to keep track of the original size for each domain. If the original size is close, two domains should be joined instead of splitted. This gives greatly enhanced results for very elongated objects, where the normal watershed algorithm tends to split the objects across several times. I hope I one day get the time and resources needed to reimplement this more complex code as an ImageJ plugin, as it works much better on objects that are not round.

Stein

-----Original Message-----
From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of Michael Schmid
Sent: 6. november 2012 11:35
To: [hidden email]
Subject: Re: MaximumFinder algorithm reference

Hi Anònim,

well, I don't know much about watershed papers, but I was working on the algorithm in ImageJ, just taking the algorithm in the previous source code as a starting point. It all dates back to the NIH Image version, written in Pascal by Wayne Rasband
  http://rsb.info.nih.gov/nih-image/download/source/Edm.p
There, see procedure DoWatershedSegmentation

Basically, it takes the result of "Find Maxima" as a seed, then dilates them. Dilation is restricted to avoid merging with another dilated area, without checking whether this other dilated area might actually belong to the same basin (it is not aware of topology, or, in other words, basins have no unique identifier). It simply checks the 8-neighborhood of a pixel that is a candidate to be set in dilation. If the already dilated pixels around it are non-contiguous, setting this pixel to the 'dilated' state is forbidden).
Details on the dilation algorithm: Dilation is always done on an 8-bit image, where dilation is done for each gray level separately: Each level has a tasklist, with all the pixels to process. The pixels in the tasklist are examined to find out whether they can be set by dilation in one of the 8 directions. This is done for all 8 directions; diagonal directions first; always a direction followed by the opposite one (i.e., first, all pixels are examined whether dilation in NW direction is possible, then the same in directions SE, NE, SW, N, S, E, W). For each level, this it is repeated until idempotence.

That's the algorithm I started with.

So, if anyone knows in what paper this algorithm is described, it would be welcome!


This algorithm works on images that are Euclidian distance maps (Process>Binary>Watershed), if each maximum is a seed. "Find Maxima" has a tolerance, so all local maxima that are below this tolerance are flattened first (the peaks are simply cut away, down to the level of the saddle point that connect it with a maximum that remains).

For image data that are not Euclidian Distance Maps, two modifications are necessary:
- Dilation may miss some areas at a given level. These must be kept on the tasklist for the next level that needs processing.
- The algorithm can result in lines that end in a single point. These do not separate basins (particles), so they are removed by post-processing.


Limitations of the algorithm:

- It is not gradient-aware. Separation lines do not run in exactly the correct direction. I did a few tries to implement a gradient method in the current algorithm, and it was kind of successful, but the code for it was so complicated that I decided I should not put it into ImageJ - in case of problems it would not be serviceable by anyone, including me :-)

- As noted above, basins have no identifier. Thus, a ring-like basin won't become a full ring in the segmentation but the ring will be split. In other words, the algorithm always results in simply connected areas.


Waiting for input by those who know the literature of watershed algorithms...

Michael
________________________________________________________________


On Nov 6, 2012, at 09:57, Anònim Anònim wrote:

> Hi all,
>
> I would like to know the theoretical background behind ImageJ's
> particle segmenter, which can be found in MaximumFinder.java. There
> are plenty of papers covering watershedding algorithms, but the code
> comments in MaximumFinder never state which one they are using; I
> could not find the answer among the mailing list discussions either.
> Any clue on the specific paper that ImageJ's implementation is based on?
>
> Thanks in advance!
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Michael Schmid]

Hi Stein,

good to know that you are still around! Your contribution of suggesting the 'tasklist' is still acknowledged in the sources; now it is in MaximumFinder.java, line 910.
  http://rsb.info.nih.gov/ij/developer/source/ij/plugin/filter/MaximumFinder.java.html

By the way, the problem of avoiding oversegmentation of an Euclidian distance map (EDM) is now treated a different way. I had some problems with the old algorithm in ImageJ <1.38c (it's a long time ago, I think there were some rare cases where Watershed gave unexpected segmentation lines, or Watershed and Ultimate Points gave inconsistent particle counts).

In short, the current algorithm for finding the 'seeds' is the following: At ridges and local maxima, the pixel value of the EDM is first corrected for the finite accuracy due to pixel discretization. Then two maxima are counted as separated only if the saddle point of these maxima is lower than the lower maximum minus 0.5 (in units of pixel size); all using these corrected values. I have tried with lots of 'test particles' and found that this works quite well.

Michael
________________________________________________________________
On Nov 6, 2012, at 13:50, Stein Rørvik wrote:

> What Michael writes here is basically correct.
>
> I did some work on this back in the mid-1990s, and used a modified algorithm in my own version of NIH image.
> If I remember correctly, the algorithm used in both my and Wayne's implementation is basically the same as the one described on pages 153-161 in the 1992 book "Computer Assisted Microscopy" by John C. Russ. That chapter explains the principle of watershed segmentation very well. Using a "task list" of pixels for each level was my idea for speeding the algorithm up; I see I am credited for that in the old NIH image source code.
>
> What I did additionally in my own implementation was to keep track of the original size for each domain. If the original size is close, two domains should be joined instead of splitted. This gives greatly enhanced results for very elongated objects, where the normal watershed algorithm tends to split the objects across several times. I hope I one day get the time and resources needed to reimplement this more complex code as an ImageJ plugin, as it works much better on objects that are not round.
>
> Stein
>
> -----Original Message-----
> From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of Michael Schmid
> Sent: 6. november 2012 11:35
> To: [hidden email]
> Subject: Re: MaximumFinder algorithm reference
>
> Hi Anònim,
>
> well, I don't know much about watershed papers, but I was working on the algorithm in ImageJ, just taking the algorithm in the previous source code as a starting point. It all dates back to the NIH Image version, written in Pascal by Wayne Rasband
>  http://rsb.info.nih.gov/nih-image/download/source/Edm.p
> There, see procedure DoWatershedSegmentation
>
> Basically, it takes the result of "Find Maxima" as a seed, then dilates them. Dilation is restricted to avoid merging with another dilated area, without checking whether this other dilated area might actually belong to the same basin (it is not aware of topology, or, in other words, basins have no unique identifier). It simply checks the 8-neighborhood of a pixel that is a candidate to be set in dilation. If the already dilated pixels around it are non-contiguous, setting this pixel to the 'dilated' state is forbidden).
> Details on the dilation algorithm: Dilation is always done on an 8-bit image, where dilation is done for each gray level separately: Each level has a tasklist, with all the pixels to process. The pixels in the tasklist are examined to find out whether they can be set by dilation in one of the 8 directions. This is done for all 8 directions; diagonal directions first; always a direction followed by the opposite one (i.e., first, all pixels are examined whether dilation in NW direction is possible, then the same in directions SE, NE, SW, N, S, E, W). For each level, this it is repeated until idempotence.
>
> That's the algorithm I started with.
>
> So, if anyone knows in what paper this algorithm is described, it would be welcome!
>
>
> This algorithm works on images that are Euclidian distance maps (Process>Binary>Watershed), if each maximum is a seed. "Find Maxima" has a tolerance, so all local maxima that are below this tolerance are flattened first (the peaks are simply cut away, down to the level of the saddle point that connect it with a maximum that remains).
>
> For image data that are not Euclidian Distance Maps, two modifications are necessary:
> - Dilation may miss some areas at a given level. These must be kept on the tasklist for the next level that needs processing.
> - The algorithm can result in lines that end in a single point. These do not separate basins (particles), so they are removed by post-processing.
>
>
> Limitations of the algorithm:
>
> - It is not gradient-aware. Separation lines do not run in exactly the correct direction. I did a few tries to implement a gradient method in the current algorithm, and it was kind of successful, but the code for it was so complicated that I decided I should not put it into ImageJ - in case of problems it would not be serviceable by anyone, including me :-)
>
> - As noted above, basins have no identifier. Thus, a ring-like basin won't become a full ring in the segmentation but the ring will be split. In other words, the algorithm always results in simply connected areas.
>
>
> Waiting for input by those who know the literature of watershed algorithms...
>
> Michael
> ________________________________________________________________
>
>
> On Nov 6, 2012, at 09:57, Anònim Anònim wrote:
>
>> Hi all,
>>
>> I would like to know the theoretical background behind ImageJ's
>> particle segmenter, which can be found in MaximumFinder.java. There
>> are plenty of papers covering watershedding algorithms, but the code
>> comments in MaximumFinder never state which one they are using; I
>> could not find the answer among the mailing list discussions either.
>> Any clue on the specific paper that ImageJ's implementation is based on?
>>
>> Thanks in advance!
>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Stein Rørvik]

Yes I am still around, but I am rarely reading the ImageJ list as I do not use it on a daily basis.
I just checked my ImageJ list inbox randomly and saw there was a question about watershed.

I see you are the original author of the new ImageJ implementation of watershed segmentation,
I will let you know if I start working on this again so we can cooperate on any improved code.

Stein

-----Original Message-----
From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of Michael Schmid
Sent: 6. november 2012 14:43
To: [hidden email]
Subject: Re: MaximumFinder algorithm reference

Hi Stein,

good to know that you are still around! Your contribution of suggesting the 'tasklist' is still acknowledged in the sources; now it is in MaximumFinder.java, line 910.
  http://rsb.info.nih.gov/ij/developer/source/ij/plugin/filter/MaximumFinder.java.html

By the way, the problem of avoiding oversegmentation of an Euclidian distance map (EDM) is now treated a different way. I had some problems with the old algorithm in ImageJ <1.38c (it's a long time ago, I think there were some rare cases where Watershed gave unexpected segmentation lines, or Watershed and Ultimate Points gave inconsistent particle counts).

In short, the current algorithm for finding the 'seeds' is the following: At ridges and local maxima, the pixel value of the EDM is first corrected for the finite accuracy due to pixel discretization. Then two maxima are counted as separated only if the saddle point of these maxima is lower than the lower maximum minus 0.5 (in units of pixel size); all using these corrected values. I have tried with lots of 'test particles' and found that this works quite well.

Michael
________________________________________________________________
On Nov 6, 2012, at 13:50, Stein Rørvik wrote:

> What Michael writes here is basically correct.
>
> I did some work on this back in the mid-1990s, and used a modified algorithm in my own version of NIH image.
> If I remember correctly, the algorithm used in both my and Wayne's implementation is basically the same as the one described on pages 153-161 in the 1992 book "Computer Assisted Microscopy" by John C. Russ. That chapter explains the principle of watershed segmentation very well. Using a "task list" of pixels for each level was my idea for speeding the algorithm up; I see I am credited for that in the old NIH image source code.
>
> What I did additionally in my own implementation was to keep track of the original size for each domain. If the original size is close, two domains should be joined instead of splitted. This gives greatly enhanced results for very elongated objects, where the normal watershed algorithm tends to split the objects across several times. I hope I one day get the time and resources needed to reimplement this more complex code as an ImageJ plugin, as it works much better on objects that are not round.
>
> Stein
>
> -----Original Message-----
> From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of
> Michael Schmid
> Sent: 6. november 2012 11:35
> To: [hidden email]
> Subject: Re: MaximumFinder algorithm reference
>
> Hi Anònim,
>
> well, I don't know much about watershed papers, but I was working on
> the algorithm in ImageJ, just taking the algorithm in the previous
> source code as a starting point. It all dates back to the NIH Image
> version, written in Pascal by Wayne Rasband  
> http://rsb.info.nih.gov/nih-image/download/source/Edm.p
> There, see procedure DoWatershedSegmentation
>
> Basically, it takes the result of "Find Maxima" as a seed, then dilates them. Dilation is restricted to avoid merging with another dilated area, without checking whether this other dilated area might actually belong to the same basin (it is not aware of topology, or, in other words, basins have no unique identifier). It simply checks the 8-neighborhood of a pixel that is a candidate to be set in dilation. If the already dilated pixels around it are non-contiguous, setting this pixel to the 'dilated' state is forbidden).
> Details on the dilation algorithm: Dilation is always done on an 8-bit image, where dilation is done for each gray level separately: Each level has a tasklist, with all the pixels to process. The pixels in the tasklist are examined to find out whether they can be set by dilation in one of the 8 directions. This is done for all 8 directions; diagonal directions first; always a direction followed by the opposite one (i.e., first, all pixels are examined whether dilation in NW direction is possible, then the same in directions SE, NE, SW, N, S, E, W). For each level, this it is repeated until idempotence.
>
> That's the algorithm I started with.
>
> So, if anyone knows in what paper this algorithm is described, it would be welcome!
>
>
> This algorithm works on images that are Euclidian distance maps (Process>Binary>Watershed), if each maximum is a seed. "Find Maxima" has a tolerance, so all local maxima that are below this tolerance are flattened first (the peaks are simply cut away, down to the level of the saddle point that connect it with a maximum that remains).
>
> For image data that are not Euclidian Distance Maps, two modifications are necessary:
> - Dilation may miss some areas at a given level. These must be kept on the tasklist for the next level that needs processing.
> - The algorithm can result in lines that end in a single point. These do not separate basins (particles), so they are removed by post-processing.
>
>
> Limitations of the algorithm:
>
> - It is not gradient-aware. Separation lines do not run in exactly the
> correct direction. I did a few tries to implement a gradient method in
> the current algorithm, and it was kind of successful, but the code for
> it was so complicated that I decided I should not put it into ImageJ -
> in case of problems it would not be serviceable by anyone, including
> me :-)
>
> - As noted above, basins have no identifier. Thus, a ring-like basin won't become a full ring in the segmentation but the ring will be split. In other words, the algorithm always results in simply connected areas.
>
>
> Waiting for input by those who know the literature of watershed algorithms...
>
> Michael
> ________________________________________________________________
>
>
> On Nov 6, 2012, at 09:57, Anònim Anònim wrote:
>
>> Hi all,
>>
>> I would like to know the theoretical background behind ImageJ's
>> particle segmenter, which can be found in MaximumFinder.java. There
>> are plenty of papers covering watershedding algorithms, but the code
>> comments in MaximumFinder never state which one they are using; I
>> could not find the answer among the mailing list discussions either.
>> Any clue on the specific paper that ImageJ's implementation is based on?
>>
>> Thanks in advance!
>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Anònim Anònim]

Thank you people. It's nice to see that the original coders are still
around...

2012/11/7 Stein Rørvik <[hidden email]>

> Yes I am still around, but I am rarely reading the ImageJ list as I do not
> use it on a daily basis.
> I just checked my ImageJ list inbox randomly and saw there was a question
> about watershed.
>
> I see you are the original author of the new ImageJ implementation of
> watershed segmentation,
> I will let you know if I start working on this again so we can cooperate
> on any improved code.
>
> Stein
>
> -----Original Message-----
> From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of
> Michael Schmid
> Sent: 6. november 2012 14:43
> To: [hidden email]
> Subject: Re: MaximumFinder algorithm reference
>
> Hi Stein,
>
> good to know that you are still around! Your contribution of suggesting
> the 'tasklist' is still acknowledged in the sources; now it is in
> MaximumFinder.java, line 910.
>
> http://rsb.info.nih.gov/ij/developer/source/ij/plugin/filter/MaximumFinder.java.html
>
> By the way, the problem of avoiding oversegmentation of an Euclidian
> distance map (EDM) is now treated a different way. I had some problems with
> the old algorithm in ImageJ <1.38c (it's a long time ago, I think there
> were some rare cases where Watershed gave unexpected segmentation lines, or
> Watershed and Ultimate Points gave inconsistent particle counts).
>
> In short, the current algorithm for finding the 'seeds' is the following:
> At ridges and local maxima, the pixel value of the EDM is first corrected
> for the finite accuracy due to pixel discretization. Then two maxima are
> counted as separated only if the saddle point of these maxima is lower than
> the lower maximum minus 0.5 (in units of pixel size); all using these
> corrected values. I have tried with lots of 'test particles' and found that
> this works quite well.
>
> Michael
> ________________________________________________________________
> On Nov 6, 2012, at 13:50, Stein Rørvik wrote:
>
> > What Michael writes here is basically correct.
> >
> > I did some work on this back in the mid-1990s, and used a modified
> algorithm in my own version of NIH image.
> > If I remember correctly, the algorithm used in both my and Wayne's
> implementation is basically the same as the one described on pages 153-161
> in the 1992 book "Computer Assisted Microscopy" by John C. Russ. That
> chapter explains the principle of watershed segmentation very well. Using a
> "task list" of pixels for each level was my idea for speeding the algorithm
> up; I see I am credited for that in the old NIH image source code.
> >
> > What I did additionally in my own implementation was to keep track of
> the original size for each domain. If the original size is close, two
> domains should be joined instead of splitted. This gives greatly enhanced
> results for very elongated objects, where the normal watershed algorithm
> tends to split the objects across several times. I hope I one day get the
> time and resources needed to reimplement this more complex code as an
> ImageJ plugin, as it works much better on objects that are not round.
> >
> > Stein
> >
> > -----Original Message-----
> > From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of
> > Michael Schmid
> > Sent: 6. november 2012 11:35
> > To: [hidden email]
> > Subject: Re: MaximumFinder algorithm reference
> >
> > Hi Anònim,
> >
> > well, I don't know much about watershed papers, but I was working on
> > the algorithm in ImageJ, just taking the algorithm in the previous
> > source code as a starting point. It all dates back to the NIH Image
> > version, written in Pascal by Wayne Rasband
> > http://rsb.info.nih.gov/nih-image/download/source/Edm.p
> > There, see procedure DoWatershedSegmentation
> >
> > Basically, it takes the result of "Find Maxima" as a seed, then dilates
> them. Dilation is restricted to avoid merging with another dilated area,
> without checking whether this other dilated area might actually belong to
> the same basin (it is not aware of topology, or, in other words, basins
> have no unique identifier). It simply checks the 8-neighborhood of a pixel
> that is a candidate to be set in dilation. If the already dilated pixels
> around it are non-contiguous, setting this pixel to the 'dilated' state is
> forbidden).
> > Details on the dilation algorithm: Dilation is always done on an 8-bit
> image, where dilation is done for each gray level separately: Each level
> has a tasklist, with all the pixels to process. The pixels in the tasklist
> are examined to find out whether they can be set by dilation in one of the
> 8 directions. This is done for all 8 directions; diagonal directions first;
> always a direction followed by the opposite one (i.e., first, all pixels
> are examined whether dilation in NW direction is possible, then the same in
> directions SE, NE, SW, N, S, E, W). For each level, this it is repeated
> until idempotence.
> >
> > That's the algorithm I started with.
> >
> > So, if anyone knows in what paper this algorithm is described, it would
> be welcome!
> >
> >
> > This algorithm works on images that are Euclidian distance maps
> (Process>Binary>Watershed), if each maximum is a seed. "Find Maxima" has a
> tolerance, so all local maxima that are below this tolerance are flattened
> first (the peaks are simply cut away, down to the level of the saddle point
> that connect it with a maximum that remains).
> >
> > For image data that are not Euclidian Distance Maps, two modifications
> are necessary:
> > - Dilation may miss some areas at a given level. These must be kept on
> the tasklist for the next level that needs processing.
> > - The algorithm can result in lines that end in a single point. These do
> not separate basins (particles), so they are removed by post-processing.
> >
> >
> > Limitations of the algorithm:
> >
> > - It is not gradient-aware. Separation lines do not run in exactly the
> > correct direction. I did a few tries to implement a gradient method in
> > the current algorithm, and it was kind of successful, but the code for
> > it was so complicated that I decided I should not put it into ImageJ -
> > in case of problems it would not be serviceable by anyone, including
> > me :-)
> >
> > - As noted above, basins have no identifier. Thus, a ring-like basin
> won't become a full ring in the segmentation but the ring will be split. In
> other words, the algorithm always results in simply connected areas.
> >
> >
> > Waiting for input by those who know the literature of watershed
> algorithms...
> >
> > Michael
> > ________________________________________________________________
> >
> >
> > On Nov 6, 2012, at 09:57, Anònim Anònim wrote:
> >
> >> Hi all,
> >>
> >> I would like to know the theoretical background behind ImageJ's
> >> particle segmenter, which can be found in MaximumFinder.java. There
> >> are plenty of papers covering watershedding algorithms, but the code
> >> comments in MaximumFinder never state which one they are using; I
> >> could not find the answer among the mailing list discussions either.
> >> Any clue on the specific paper that ImageJ's implementation is based on?
> >>
> >> Thanks in advance!
> >>
> >> --
> >> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
> >
> > --
> > ImageJ mailing list: http://imagej.nih.gov/ij/list.html
> >
> > --
> > ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html