Hey Guillaume,<div><br></div><div>Thanks for the report. See below:<br><br><div class="gmail_quote">On Fri, Apr 13, 2012 at 6:18 AM, Guillaume Gay <span dir="ltr"><<a href="mailto:guillaume@mitotic-machine.org" target="_blank">guillaume@mitotic-machine.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
When calling feature.peak_local_max() on a flat image, all the points of the image are returned:<br>
<br>
>>> test_image = np.ones((10,10))<br>
>>> coords = feature.peak_local_max()<br>
>>> len(coords)<br>
 100<br>
<br>
I wouldn't expect that... It originates from two things in the code:<br>
<br>
1. The calculated thershold can be higher than the min  of the image:<br>
<br>
    corner_threshold = np.max(image.ravel()) * threshold<br></blockquote><div><br></div><div><br></div><div>You mean: the calculated threshold can be *less than* the min of the image, correct? </div><div><br></div><div>Hmm, I'm not sure if this is necessarily a bug: using a relative threshold can be problematic, but  the same is true for absolute thresholds (you can easily set the absolute threshold below the min of the image).</div>

<div><br></div><div>One alternative would be to calculate the relative threshold based on the range of input values. For example, setting `threshold=0.5` would given a threshold that's half-way between the minimum and maximum pixel intensities. (BTW, I was wondering why I named this "corner"_threshold; then I remembered that I refactored this from the Harris corners implementation)</div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2. All points higher *or equal* to the threshold are retrieved:<br>
<br>
    image_t = (image >= corner_threshold) * 1<br>
<br>
So for me this is a bit strange, and is really bad when you have an empty frame on a sequence, which tends to happen.</blockquote><div><br></div><div><br></div><div>This is a good point. I'd be happy to change `>=` to `>`: I think it would help avoid some corner-cases, and I can't see any significant side-effects. In addition, I think it may be worthwhile to raise an error if all values are equal.</div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Also I think the threshold argument is a bit unusual, I more often expect an absolute value for the threshold, not a relative one.<br>

<br></blockquote><div><br></div><div>I think relative thresholding is really useful. Sometimes you don't know the strength of your peak (esp. in some image transforms), and it's easy to just say that valid peaks are some fraction of the maximum peak.</div>

<div><br></div><div>That said, I think that it'd be worthwhile to have both absolute and relative thresholding. I'm not sure about the naming though:</div><div><br></div><div>- `athresh` and `rthresh`</div><div>- `absthresh` and `relthresh`</div>

<div>- `abs_thresh` and `rel_thresh`</div><div>- `abs_threshold` and `rel_threshold`</div><div><br></div><div>Thoughts?</div><div><br></div><div>-Tony</div></div></div>