Mailman 3 October 2011 - scikit-image

Image data type ranges
by Neil Yager 26 Oct '11

26 Oct '11

I was having conversation about data types with Stéfan in the line comments of a PR, and I thought I should move it here so others can benefit from his explanations as well. Being new to the project, I didn't appreciate the intricacies of data typing. For example, I was surprised to see that this raises a ValueError: >>> skimage.img_as_float(np.arange(9).reshape((3, 3))) The problem is that the default dtype of np.arange is int32, which isn't supported by skimage, so img_as_float doesn't know how to scale it to [0, 1]. Perhaps it is correct to fail, as it will force the user to consider the data type issue. However, it does seem like a reasonable/common thing to want to do. A related, but different, issue is the following: >>> x = np.arange(9, dtype=np.uint8).reshape((3, 3)) >>> x array([[0, 1, 2], [3, 4, 5], [6, 7, 8]], dtype=uint8) >>> y = skimage.img_as_ubyte(x.astype(np.float32)) WARNING:dtype_converter:Possible precision loss, converting from float32 to uint8 >>> y array([[ 0, 255, 254], [253, 252, 251], [250, 249, 248]], dtype=uint8) The problem here is that the input to img_as_ubyte violates skimage's assumption that floating point images have the range [0, 1], leading to an unexpected result (at least for a beginner). There is a warning, but that's for a different problem. Should img_as_ubyte, img_as_float, etc. check and enforce ranges? Or raise warnings? Any thoughts? Neil

1 0

Re: Renaming scikits.image to skimage
by Neil Yager 25 Oct '11

25 Oct '11

The problem is that the image in test_homography() is of type numpy.int32, which scipy.ndimage.interpolation.geometric_transform() doesn't support (at least for scipy 0.9.0). I've submitted a PR for the fix. Neil On Oct 25, 9:05 am, Neil Yager <yager.n...(a)gmail.com> wrote: > > I'm running cython 14.1 and numpy dev (and scipy dev), so my system isn't > > exactly a match. But I can't imagine how these differences could change the > > test behavior before and after the renaming. Are you sure the test passed > > before the rename? > > I'm getting the same error before and after the rename. Numpy 1.6.1 > and Cython 0.15 > > Neil

1 0

Re: Renaming scikits.image to skimage
by Stéfan van der Walt 25 Oct '11

25 Oct '11

Remind me which error again? On Oct 25, 2011 1:15 AM, "Neil Yager" <yager.neil(a)gmail.com> wrote: > > I'm running cython 14.1 and numpy dev (and scipy dev), so my system isn't > > exactly a match. But I can't imagine how these differences could change > the > > test behavior before and after the renaming. Are you sure the test passed > > before the rename? > > I'm getting the same error before and after the rename. Numpy 1.6.1 > and Cython 0.15 > > Neil >

1 0

Re: Renaming scikits.image to skimage
by Neil Yager 25 Oct '11

25 Oct '11

> I'm running cython 14.1 and numpy dev (and scipy dev), so my system isn't > exactly a match. But I can't imagine how these differences could change the > test behavior before and after the renaming. Are you sure the test passed > before the rename? I'm getting the same error before and after the rename. Numpy 1.6.1 and Cython 0.15 Neil

1 0

Re: Roadmap to 0.4
by Stéfan van der Walt 25 Oct '11

25 Oct '11

2011/10/23 Stéfan van der Walt <stefan(a)sun.ac.za>: > - Support for multiple computation back-ends Would anyone like to comment on this issue? Stéfan

1 0

Roadmap to 0.4
by Stéfan van der Walt 24 Oct '11

24 Oct '11

Hi all, Emmanuelle mentioned that it would be useful to have a list of PRs and their priorities for the next release. Also read on for design decisions, and other minor tasks. *PRs almost ready to merge: * - https://github.com/scikits-image/scikits-image/pull/65 Add medial axis skeletonization. Neil Yager's skeletonization code has already been merged, and this is the version from cellprofiler. *PRs requiring minor refactoring / cleanup: * - https://github.com/scikits-image/scikits-image/pull/13 Template matching. Needs to be modified to use existing integral_image, and the example needs to be converted to the right format. - https://github.com/scikits-image/scikits-image/pull/61 Fix for correctly converting alpha-layered images to gray. It's a minor fix, but this PR does it in the wrong place. *PRs requiring more work:* - https://github.com/scikits-image/scikits-image/pull/41 Structural similarity indices. Would be great to have, but PR comments need to be addressed. - https://github.com/scikits-image/scikits-image/pull/16 Fast convolution using SSE2 instructions. This is a proof of concept done by Pieter Holtzhausen for GSoC. It needs to be updated to use zeros outside image boundaries. We also need benchmarks, and to remove opencv dependencies in the tests. *Other remaining tasks:* * * - Update Debian license info (I never finished this) - Write a man-page for "scivi" - While our Debian package should probably be "python-scikits-image", the scikit-learn guys already called theirs "sklearn", so the Debian package needs to be updated to this convention - Update Cython build script to generate hashes of .pyx files so that we don't always re-generate Cython, even on clean builds - Write examples and docs (especially narrative docs)! *Design Decisions: * - Support for multiple computation back-ends Pieter Holtzhausen has a PR in the queue for this after his GSoC. The idea is to provide a way for users to write code that make use of alternative computation backends, e.g. OpenCL, but without requiring the scikits-image developers to pick up that burden. For example, you could do: use_backend('opencl') import skimage as ski ski.do_some_stuff() ski.do_some_more_stuff() The user would provide the OpenCL implementation, but can easily fall back to pure scikits-image by removing the first line. The question here is: are we all agreed that this is a good idea? It increases the package flexibility a lot, at the cost of some code complexity (hopefully mostly hidden from the user). Allright, I think that's about it. We have another week to include new changes before 0.4, so feel free to file new pull requests until then. Thanks, all! Stéfan

1 0

Package rename, repo move complete
by Stéfan van der Walt 24 Oct '11

24 Oct '11

Hi all, I've merged the pull request by Nelle Varoquaux for renaming the package to "skimage". Please note that: 1) Code needs to be updated to read "from skimage import ..." instead of "from scikits.image import ...". 2) The repository has moved, and now lives at https://github.com/scikits-image/scikits-image git@github.com:scikits-image/scikits-image.git Please scan the docs, build scripts, etc. and make sure we didn't miss anything! Nelle, thanks for taking the trouble to do this! Stéfan

1 0

Re: Renaming / 0.4 timeline
by Emmanuelle Gouillart 24 Oct '11

24 Oct '11

> Tue Oct 18th to Sat Oct 22nd : File and merge PRs of work-in-progress > made against the current repo I've merged Neil's skeletonization PR and filed a new PR with a refactored version of cell profiler's skeletonize algorithm (now called medial axis). Neil, would you have the time to review this code? https://github.com/scikits-image/scikits.image/pull/65 StÃ¯Â¿Â½fan, could you make a list of open PRs (as you had done for 0.3) with priorities (those that have to be merged before the release) and requests for help on code reviewing, if needed? The renaming PR surely has to be merged, but it will be the last one. If the authors of open PRs can also say when they will be finished implementing suggestions / if they have already done so / if they are waiting for feedback, that would also help for the planning... Cheers, Emmanuelle

2 1

Re: Pull request: morphology fix
by Andreas Mueller 20 Oct '11

20 Oct '11

On 10/19/2011 08:44 PM, StÃ¯Â¿Â½fan van der Walt wrote: > On Wed, Oct 19, 2011 at 9:57 AM, Ralf Gommers > <ralf.gommers(a)googlemail.com> wrote: >>> Does anyone here have experience with such approaches? >>> >> scipy.interpolate has Cython code with simple Mako templating, look at >> interpnd.pyx and generate_interpnd.py. If it's flexible enough for your >> needs then it'll be a lot more pleasant than using C++. > This definitely gets us some way. We can modify our _build.cython > call to first run the template engine on any .tpyx files. > > But how should we dispatch to different functions, based on dtype? > Let's say we have support for int16, uint16 and double in our > algorithm, so via templating we'll get > > myfunc_int16 > myfunc_uint16 > myfunc_double > > for a single input argument (which is the most common case). We can > then define a dispatch call such as > > dtype_call('myfunc', img.dtype) > > which calls the appropriate function. Does this sound about right? Sounds sensible. Doing the overloading "by hand" looks a bit ugly but it seems cython does not do overloading of cython functions: http://wiki.cython.org/enhancements/overloading Overloaded C++ functions on the other hand seem to be no problem <http://wiki.cython.org/WrappingCPlusPlus>.

2 1

Re: Pull request: morphology fix
by Stéfan van der Walt 20 Oct '11

20 Oct '11

On Wed, Oct 19, 2011 at 9:57 AM, Ralf Gommers <ralf.gommers(a)googlemail.com> wrote: >> Does anyone here have experience with such approaches? >> > scipy.interpolate has Cython code with simple Mako templating, look at > interpnd.pyx and generate_interpnd.py. If it's flexible enough for your > needs then it'll be a lot more pleasant than using C++. This definitely gets us some way. We can modify our _build.cython call to first run the template engine on any .tpyx files. But how should we dispatch to different functions, based on dtype? Let's say we have support for int16, uint16 and double in our algorithm, so via templating we'll get myfunc_int16 myfunc_uint16 myfunc_double for a single input argument (which is the most common case). We can then define a dispatch call such as dtype_call('myfunc', img.dtype) which calls the appropriate function. Does this sound about right? Regards Stéfan

1 0