Mailman 3 July 2013 - scikit-image

Re: Qhull error
by Juan Nunez-Iglesias 11 Jul '13

11 Jul '13

This is all very weird. Stefan, no, I didn't figure it out, I just implemented my proposal of having a try/except around it and setting it to 1.1 if the error came up! =) It was a minority of my objects and I chuck out outliers anyway... Chintak's finding suggests a more Pull-Requestable way forward... =) On Wed, Jul 10, 2013 at 2:52 PM, Chintak Sheth <chintaksheth(a)gmail.com>wrote: > Hi Juan, > > I tried computing `convex_hull_image` of `test_im` directly and as > expected got the error you posted above. > > Then I tried to run `regionprops` on the `test_im` padded with 0s. This > again threw the same error. But oddly so, direct computation of > `convex_hull_image` of padded `test_im` does give a result! In spite of the > traceback showing that the problem originated in `convex_hull_image` > function. > > At least for the purposes of your problem you can probably compute the > Solidity manually here. > > ``` > In [27]: a = np.zeros((5,9), int) > > In [28]: a > Out[28]: > array([[0, 0, 0, 0, 0, 0, 0, 0, 0], > [0, 0, 0, 0, 0, 0, 0, 0, 0], > [0, 0, 0, 0, 0, 0, 0, 0, 0], > [0, 0, 0, 0, 0, 0, 0, 0, 0], > [0, 0, 0, 0, 0, 0, 0, 0, 0]]) > > In [29]: a[1:-1, 1:-1] = test_im > > In [30]: a > Out[30]: > array([[0, 0, 0, 0, 0, 0, 0, 0, 0], > [0, 0, 0, 0, 0, 1, 0, 0, 0], > [0, 0, 0, 1, 1, 1, 1, 1, 0], > [0, 1, 1, 1, 0, 0, 0, 0, 0], > [0, 0, 0, 0, 0, 0, 0, 0, 0]]) > > In [31]: b = convex_hull_image(a).astype(int) > > In [32]: b > Out[32]: > array([[0, 0, 0, 0, 0, 0, 0, 0, 0], > [0, 0, 0, 0, 1, 1, 1, 0, 0], > [0, 0, 1, 1, 1, 1, 1, 1, 0], > [0, 1, 1, 1, 1, 0, 0, 0, 0], > [0, 0, 0, 0, 0, 0, 0, 0, 0]])``` > > Thanks, > Chintak > > -- > You received this message because you are subscribed to the Google Groups > "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to scikit-image+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > >

1 0

Re: Weird imsave inverting behaviour
by Juan Nunez-Iglesias 11 Jul '13

11 Jul '13

I'd be interested in tackling this, but a number of alternatives were proposed, including my io.png.read() and Johannes's plugin registry thingy, with no clear decision on which way to go... On Wed, Jul 10, 2013 at 1:39 PM, Stéfan van der Walt <stefan(a)sun.ac.za>wrote: > On Wed, Jun 5, 2013 at 10:15 AM, Juan Nunez-Iglesias <jni.soma(a)gmail.com> > wrote: > > I'd argue yes. ;) But I'm not sure any hard conclusions were reached as > to > > what exactly needs to be done. I guess the first thing is fixing the TIFF > > input bug, before any more refactoring. But that might go away in a > refactor > > anyway... > > We need to a) refactor the I/O infrastructure which b) should allow > plugins to describe their supported functionality. > > Another option would be to get rid of plugins, and to provide a > directory of snippets that illustrate how to load various other file > formats with skimage. > > Stéfan > > -- > You received this message because you are subscribed to the Google Groups > "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to scikit-image+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > >

1 0

Re: Qhull error
by Chintak Sheth 10 Jul '13

10 Jul '13

Hi Juan, I tried computing `convex_hull_image` of `test_im` directly and as expected got the error you posted above. Then I tried to run `regionprops` on the `test_im` padded with 0s. This again threw the same error. But oddly so, direct computation of `convex_hull_image` of padded `test_im` does give a result! In spite of the traceback showing that the problem originated in `convex_hull_image` function. At least for the purposes of your problem you can probably compute the Solidity manually here. ``` In [27]: a = np.zeros((5,9), int) In [28]: a Out[28]: array([[0, 0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0, 0]]) In [29]: a[1:-1, 1:-1] = test_im In [30]: a Out[30]: array([[0, 0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 1, 0, 0, 0], [0, 0, 0, 1, 1, 1, 1, 1, 0], [0, 1, 1, 1, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0, 0]]) In [31]: b = convex_hull_image(a).astype(int) In [32]: b Out[32]: array([[0, 0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 1, 1, 1, 0, 0], [0, 0, 1, 1, 1, 1, 1, 1, 0], [0, 1, 1, 1, 1, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0, 0]])``` Thanks, Chintak

1 0

Re: Weird imsave inverting behaviour
by Stéfan van der Walt 10 Jul '13

10 Jul '13

On Wed, Jun 5, 2013 at 10:15 AM, Juan Nunez-Iglesias <jni.soma(a)gmail.com> wrote: > I'd argue yes. ;) But I'm not sure any hard conclusions were reached as to > what exactly needs to be done. I guess the first thing is fixing the TIFF > input bug, before any more refactoring. But that might go away in a refactor > anyway... We need to a) refactor the I/O infrastructure which b) should allow plugins to describe their supported functionality. Another option would be to get rid of plugins, and to provide a directory of snippets that illustrate how to load various other file formats with skimage. Stéfan

1 0

GSoC Proposal
by Marc de Klerk 10 Jul '13

10 Jul '13

Hello Everyone, I just wanted to post my proposal for the GSoC: https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/dek… I hope it sparks a bit of interest :) Looking forward to hearing any feedback... Cheers Marc

2 2

Re: Qhull error
by Stéfan van der Walt 10 Jul '13

10 Jul '13

On Thu, Jun 13, 2013 at 8:52 AM, Juan Nunez-Iglesias <jni.soma(a)gmail.com> wrote: > Hi all. I'm getting the below error when computing regionprops(..., > ['Solidity']). Does anyone know what's going on? At first I thought maybe it > was passing a singleton array or something, but this array looks like a > reasonable thing to compute a convex hull on, no? Yikes, did you ever figure out what was wrong here? I've seen behavior like this in SciPy's delaunay before, but never managed to dig down to the root of the issue. Stéfan

1 0

Re: source compilation error: undefined references
by Evan 10 Jul '13

10 Jul '13

On Thursday, June 13, 2013 1:55:02 PM UTC+2, Stefan van der Walt wrote: > > On Thu, Jun 13, 2013 at 11:43 AM, Evan <evan...(a)gmail.com <javascript:>> > wrote: > > Thanks for your reply. Can you coach me a little on the modification I > need > > to make. I assume the file to edit is: > > ... /scikit-image-0.8.2/skimage/_shared/setup.py > > But so far I don't see how to resolve what's needed from > > http://docs.cython.org/src/tutorial/external.html#dynamic-linking into > the > > setup file. > > Yes, you need to add the 'libraries=["m"]' part. > > Stéfan > Ok, got it. Had to work through and edit each each subdir + setup.py as needed. I'll send the pull request in the next day or two. Thanks very much for the help, Evan

2 1

Picture of espresso
by Stéfan van der Walt 08 Jul '13

08 Jul '13

Dear scikit-imagers For those of you who enjoy the finer beverages in life, a request. We are looking for a good photo of a shot of espresso for a Hough ellipse/circle detector. See: https://github.com/scikit-image/scikit-image/pull/641/ Since we need it to be public domain, your help in taking such a photograph would be much appreciated! Stéfan

1 0

Re: Cython guidelines
by Stéfan van der Walt 08 Jul '13

08 Jul '13

On Tue, Jul 2, 2013 at 1:45 AM, Juan Nunez-Iglesias <jni.soma(a)gmail.com> wrote: > Cython + pointers is just as fast as memoryviews. And on SLIC at least, you > made liberal use of pointers. =) I just tried my hand at memoryviews at > Stéfan's request and it's quite a bit slower currently. For anyone coming across this thread later: we found the bug, and memoryviews are about as fast as pointers. Stéfan

1 0

Re: GLCM with scikit-image
by Stéfan van der Walt 08 Jul '13

08 Jul '13

On Mon, Jul 8, 2013 at 2:45 PM, <elyraz(a)mail.com> wrote: > - Does the "skimage.dtype_converter: WARNING: Possible precision loss when > converting from float64 to uint8" means that the output values are wrong? Not wrong, just that there was a conversion between floating point and integer values, which means it had to drop some precision along the way. Stéfan

1 0