Mailman 3 April 2012 - scikit-image

vbench
by Tony Yu 25 Apr '12

25 Apr '12

I just uploaded a PR to add the basic setup for code profiling using Wes McKinney's `vbench` <http://wesmckinney.com/blog/?p=373>: PR 180<https://github.com/scikits-image/scikits-image/pull/180>. (You'll have to install vbench <https://github.com/pydata/vbench> to actually run the benchmarks.) This PR adds the basic infrastructure for benchmarking; I'm thinking that the benchmarks themselves can be added incrementally. Right now it takes a surprisingly-long time to run; this may be an issue with how I've set it up, but I'm not sure. These files are from the pandas vbench suite with a bit of modification. For a direct comparison with the pandas suite<https://github.com/wesm/pandas/tree/master/vb_suite>, I've renamed: suite.py -> settings.py run_suite.py -> run_benchmarks.py and instead of putting the test files in the same directory as these files, I've dumped them into the "suite" subdirectory. If you want to try it out, you'll have to install vbench, and you'll probably want to uncomment the alternate start date in settings.py (even so, it still takes a surprisingly long time to run on my system). Running `make` will generate a "source" directory, which contains restructuredtext files for displaying the benchmarking output (source->vbench->figures contains the relevant plots). As an example, I've attached the result for calling `img_as_ubyte` on an `int` image. Note the sharp drop in execution time in early February: this is when Christophe Gohlke's PR for dtype conversion (PR #99<https://github.com/scikits-image/scikits-image/pull/99>) was finally merged. Cheers, -Tony

1 0

Re: HoG bug?
by Stéfan van der Walt 20 Apr '12

20 Apr '12

Hi David On Fri, Apr 20, 2012 at 12:41 PM, David Stolarsky <david.stolarsky(a)gmail.com> wrote: > It looks to me like the HoG computation ignores half of the possible > gradient values (see attached image). There are 15 lines visible in the > attached HoG visualization, likewise there are 15 non-zero values in the > feature vector returned by feature.hog(). Is this a bug? Am I doing > something wrong? I'm using the hog example script > from http://scikits-image.org/docs/0.5/auto_examples/plot_hog.html , > modified to take a file from the command line. I don't have access to your input image, but I suspect what's happening is that when the image is divided up into 8x8 cells, the top edges fall on the boundaries of cells, while the bottom ones fall inside. If you send me the input image, I can verify, or you can modify the cell shape to see what happens. Stéfan

1 0

HoG bug?
by David Stolarsky 20 Apr '12

20 Apr '12

It looks to me like the HoG computation ignores half of the possible gradient values (see attached image). There are 15 lines visible in the attached HoG visualization, likewise there are 15 non-zero values in the feature vector returned by feature.hog(). Is this a bug? Am I doing something wrong? I'm using the hog example script from http://scikits-image.org/docs/0.5/auto_examples/plot_hog.html , modified to take a file from the command line. Best, David

1 0

Re: Unexpected behaviour in peak_local_max
by Guillaume Gay 16 Apr '12

16 Apr '12

Great, Thank's Tony for the fixes Best, Guillaume Le 16/04/2012 06:29, Tony Yu a écrit : > > > 2012/4/15 Stéfan van der Walt <stefan(a)sun.ac.za <mailto:stefan@sun.ac.za>> > > On Sun, Apr 15, 2012 at 2:23 PM, Tony Yu <tsyu80(a)gmail.com > <mailto:tsyu80@gmail.com>> wrote: > > 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` > > `threshold_abs` and `threshold_rel` perhaps? My personal preference > is to have the specialization afterwards. > > Stéfan > > > Sounds good. I've added these parameters (along w/ a few other > changes) in PR #176 > <https://github.com/scikits-image/scikits-image/pull/176>. > > -Tony >

1 0

Re: Unexpected behaviour in peak_local_max
by Tony Yu 16 Apr '12

16 Apr '12

2012/4/15 Stéfan van der Walt <stefan(a)sun.ac.za> > On Sun, Apr 15, 2012 at 2:23 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > > 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` > > `threshold_abs` and `threshold_rel` perhaps? My personal preference > is to have the specialization afterwards. > > Stéfan > Sounds good. I've added these parameters (along w/ a few other changes) in PR #176 <https://github.com/scikits-image/scikits-image/pull/176>. -Tony

1 0

Re: Unexpected behaviour in peak_local_max
by Stéfan van der Walt 15 Apr '12

15 Apr '12

On Sun, Apr 15, 2012 at 2:23 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > 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` `threshold_abs` and `threshold_rel` perhaps? My personal preference is to have the specialization afterwards. Stéfan

1 0

bug in radon transform?
by Emmanuelle Gouillart 15 Apr '12

15 Apr '12

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

4 3

Re: bug in radon transform?
by Emmanuelle Gouillart 09 Apr '12

09 Apr '12

Yes, it looks weird. I don't have access to the corresponding toolbox in Matlab either. I could "symmetrize" the result by the following change in radon: - shift0 = np.array([[1, 0, -w/2.], - [0, 1, -h/2.], + shift0 = np.array([[1, 0, -w/2. + 0.5], + [0, 1, -h/2. + 0.5], [0, 0, 1]]) - shift1 = np.array([[1, 0, w/2.], - [0, 1, h/2.], + shift1 = np.array([[1, 0, w/2. - 0.5], + [0, 1, h/2. - 0.5], [0, 0, 1]]) but then I'm not sure whether the behavior of iradon is correct either, so I haven't committed this change yet. Pieter, if you're around, would you mind having a quick look? Also, iradon crashes for arrays with less than 64 lines (due to an int that should be a float, resulting in a division by zero error -- I just made a small pull request to correct that). I also noticed that for the array used in test_radon_transform.test_radon_iradon, applying radon and then iradon does not give back the correct original array, but an array that looks shifted by one line and one column. Try for example >>> from skimage.transform import radon, iradon >>> size = 70 >>> image = np.tri(size) + np.tri(size)[::-1] >>> reconstructed = iradon(radon(image), filter="ramp", >>> interpolation="linear") >>> close('all') >>> plt.matshow(image) <matplotlib.image.AxesImage object at 0x42f9b90> >>> plt.matshow(reconstructed) <matplotlib.image.AxesImage object at 0x494a5d0> I very much suspect that the center of rotation is not correct either in radon, or in iradon, or maybe in both... I started having a look at the code, but maybe it would be easier for Pieter than for me to fix it... Cheers, Emmanuelle On Wed, Apr 04, 2012 at 03:53:38PM -0700, StÃ¯Â¿Â½fan van der Walt wrote: > On Wed, Apr 4, 2012 at 2:31 PM, Emmanuelle Gouillart > <emmanuelle.gouillart(a)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

1 0

Re: [OT] pass a C callback function to a cythom module via python
by Chris Colbert 02 Apr '12

02 Apr '12

On Mon, Apr 2, 2012 at 1:29 PM, Nadav Horesh <nadavh.horesh(a)gmail.com>wrote: > I do not have a benchmark code yet. I am working now on unpythonising the > in-loop buffer copy (the line "neigh[:] = self.padded[i:i+ks0, > j:j+ks1].ravel()" in filter_iter.pyx)/ When I'll finish this and include > your suggestion, I'll be ready for the benchmarking. > > My experience with the bilateral filter showed that yellowish lines do > not comply with nogil, but it is easy to verify again. > > More specifically, anything that makes a call into the Python C-Api is not compatible with nogil. Since, Cython highlights these lines in yellow, your understanding is correct.

1 0

Re: Platform for filters development
by Nadav Horesh 02 Apr '12

02 Apr '12

Thank you for shaping it up. I'll base the next updates on this form. Nadav. N.B I deliberately use cython-0.15(.1) as employing openmp (via prange) in on my todo list. בתאריך 27 במרץ 2012 06:08, מאת Tony Yu <tsyu80(a)gmail.com>: > >> >> >> On Wed, Mar 21, 2012 at 12:05 PM, Nadav Horesh <nadavh.horesh(a)gmail.com>wrote: >> >>> (I think I missed the attachment) >>> >>> >>> Attached here a concept code showing my attempt to produce in improved >>> (over ndimage.generic_filter) platform for filters development. The code is >>> very preliminary and needs a lot of extension as well as rewrite. My main >>> questions are: >>> >>> 1. Is there is already a mature package for this purpose? >>> 2. Is there is need for such a module inside scikits? >>> >>> Any comment is welcome. >>> >>> Nadav >>> >> >> Hey Nadav, >> >> I had some problems building this example. (Actually, I couldn't even >> unzip it at first.) In case anyone else wants to try this out, I posted a version >> of your package <https://github.com/tonysyu/filter_iter> to my github >> account with some build modifications. I think the build requires Cython >> 0.15 (or at least, I think so: I was getting some build errors with 0.14 >> and upgrading seemed to fix it (although I may have made other changes >> along the way).) >> >> I haven't yet had time to play around with the code, so I don't have >> anything constructive to say about the code yet. >> >> Cheers, >> -Tony >> >

1 0