Hello, I have the impression that the center of rotation used for computing the radon transform (skimage.transform.radon) is not correct:
import numpy as np from skimage.transform import radon, iradon
a = np.zeros((3, 3)) a[1, 1] = 1 projs = radon(a, [0, 45, 90, 135]) projs array([[ 0. , 0. , 0. , 0. ], [ 0. , 0. , 0. , 0.13603897], [ 0. , 0.46446609, 1. , 0.79289322], [ 1. , 0.46446609, 0. , 0. ], [ 0. , 0. , 0. , 0. ], [ 0. , 0. , 0. , 0. ], [ 0. , 0. , 0. , 0. ]])
(the projection at 90�C, that is projs[2], should have the non-zero coefficient centered). Before I try to modify this, I'd like to be sure that it is not the expected behaviour, and a bug indeed... Cheers, Emmanuelle
On Wed, Apr 4, 2012 at 2:31 PM, Emmanuelle Gouillart <emmanuelle.gouillart@nsup.org> wrote:
I have the impression that the center of rotation used for computing the radon transform (skimage.transform.radon) is not correct:
In [8]: tf.radon(z, theta=[0, 90]) Out[8]: array([[ 0., 0.], [ 0., 0.], [ 0., 1.], [ 0., 0.], [ 0., 0.], [ 0., 0.], [ 1., 0.], [ 0., 0.], [ 0., 0.], [ 0., 0.]]) Hrm, you're right; that looks fishy. I wonder if this has to do with the padding that happens beforehand? I don't have access to MATLAB--does their "radon" give similar results? Stéfan
Hi all, When calling feature.peak_local_max() on a flat image, all the points of the image are returned:
test_image = np.ones((10,10)) coords = feature.peak_local_max() len(coords) 100
I wouldn't expect that... It originates from two things in the code: 1. The calculated thershold can be higher than the min of the image: corner_threshold = np.max(image.ravel()) * threshold 2. All points higher *or equal* to the threshold are retrieved: image_t = (image >= corner_threshold) * 1 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. Also I think the threshold argument is a bit unusual, I more often expect an absolute value for the threshold, not a relative one.
Hey Guillaume, Thanks for the report. See below: On Fri, Apr 13, 2012 at 6:18 AM, Guillaume Gay < guillaume@mitotic-machine.org> wrote:
Hi all,
When calling feature.peak_local_max() on a flat image, all the points of the image are returned:
test_image = np.ones((10,10)) coords = feature.peak_local_max() len(coords) 100
I wouldn't expect that... It originates from two things in the code:
1. The calculated thershold can be higher than the min of the image:
corner_threshold = np.max(image.ravel()) * threshold
You mean: the calculated threshold can be *less than* the min of the image, correct? 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). 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)
2. All points higher *or equal* to the threshold are retrieved:
image_t = (image >= corner_threshold) * 1
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.
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.
Also I think the threshold argument is a bit unusual, I more often expect an absolute value for the threshold, not a relative one.
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. That said, I think that it'd be worthwhile to have both absolute and relative thresholding. I'm not sure about the naming though: - `athresh` and `rthresh` - `absthresh` and `relthresh` - `abs_thresh` and `rel_thresh` - `abs_threshold` and `rel_threshold` Thoughts? -Tony
participants (4)
-
Emmanuelle Gouillart -
Guillaume Gay -
Stéfan van der Walt -
Tony Yu