Mailman 3 April 2013 - scikit-image

Re: New core developer: Josh Warner
by Juan Nunez-Iglesias April 23, 2013

April 23, 2013

Congrats Josh! Looking forward to joining you at some point. ;) On Tue, Apr 23, 2013 at 5:08 AM, Tony Yu <tsyu80(a)gmail.com> wrote: > Hi everyone, > > I'd like to officially welcome Josh Warner to the scikit-image development > team. Josh has been contributing to the project for the last year and a > half, starting with some improvements for random walker segmentation. > Lately, he has been really active reviewing our back log of pull requests > and closing bugs. > > We're looking forward to all the new contributions you'll be able make > given your new powers :) > > Cheers, > -Tony > > -- > 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: Test failures in graph subpackage
by Stéfan van der Walt April 23, 2013

April 23, 2013

On Tue, Apr 23, 2013 at 9:29 AM, Chintak Sheth <chintaksheth(a)gmail.com> wrote: > +1, oddly so almost all the recent PRs are facing an issue with Travis > build. I just merged Josh's PR to address this problem, so we can again rely on Travis output. Stéfan

1 0

Re: Test failures in graph subpackage
by Josh Warner April 23, 2013

April 23, 2013

I think I found the problem. Originally, these tests all passed on OSX, Win7, and Scientific Linux. Then I looked into what versions Travis was installing, and the only package newer than what I was running was Cython 0.19. So upgraded Cython to 0.19 using pip (installed with no errors; had 0.17 or 0.18 previously) with no other changes in my config. Then after `$ make clean`, rebuilt scikit-image inplace, and `$ make install` I can reproduce these failures on Scientific Linux. I renamed and kept the old _mcp.c file to compare with the new version; if that diff is potentially of interest I can post it or the full file(s) on pastebin or a gist. Josh On Saturday, April 20, 2013 3:32:16 PM UTC-5, Tony S Yu wrote: > > Can anyone reproduce the test failures that the Travis buildbot is raising > on master: > > https://travis-ci.org/scikit-image/scikit-image/jobs/6472929#L2274 > > The tests pass on my setup, so I can't really figure out what's wrong. > > Thanks, > -Tony >

3 3

New core developer: Josh Warner
by Tony Yu April 22, 2013

April 22, 2013

Hi everyone, I'd like to officially welcome Josh Warner to the scikit-image development team. Josh has been contributing to the project for the last year and a half, starting with some improvements for random walker segmentation. Lately, he has been really active reviewing our back log of pull requests and closing bugs. We're looking forward to all the new contributions you'll be able make given your new powers :) Cheers, -Tony

1 0

Re: Describing superpixels
by Stéfan van der Walt April 22, 2013

April 22, 2013

On Mon, Apr 22, 2013 at 11:55 AM, Juan Nunez-Iglesias <jni.soma(a)gmail.com> wrote: > It's very convenient to have direct access back to the pixels/voxels making > up each superpixel. Therefore, I stored on each node an array containing all > the linear indices into the `ravel`ed version of the image. This is pretty > expensive, though, so if could do it over, I would store the index of a > single pixel belonging to that superpixel and pair it with a flood fill > algorithm, so that a function `g.get_pixel_indices(superpixel_id)` would > transparently return the pixel list, but in O(superpixel_size) time while > only using up a singe int of space. Thanks for sharing that good advice. Juan. There is also an intermediary storage format, one that I used before with some success. Think of a 2-D example: you store the start and end indices of each column that comprises the object, paired with an index into the rows (very similar to CSR). Perhaps it will be a bit painful to extend to N-d, but it is doable. Another option is to store a graph in an array. This goes along very well with the implementation of ``graph.label``. At each position in the array, you store the index of the previous pixel to which it is connected. For any super-pixel, you can then store only the last pixel, and traverse indices backward to get the entire super-pixel. Con: 2 x storage. > Related note: does skimage have an nd implementation of flood fill? I think one of the recent PRs made an attempt at a 2D version called ``connected_component``, but otherwise no. Stéfan

1 0

Re: imageio progress
by Juan Nunez-Iglesias April 22, 2013

April 22, 2013

On Mon, Apr 22, 2013 at 7:46 PM, Stéfan van der Walt <stefan(a)sun.ac.za>wrote: > It doesn't quite cover our use-case of supporting multiple readers for the > same format, but then I also don't know if that is ideal. > I don't know either. ;) I noticed that you used multiple plugins, but I haven't been a fan. I think, as you suggested, that the user shouldn't have to worry about these things unless he wants to. So, use a default backend, whatever we think is best for each format. Then, if the user wants to use a specific one, he can write (for example): io.png.set_backend('PIL') This'd be interesting to engineer I bet. =)

1 0

Re: Describing superpixels
by Guillaume Gay April 22, 2013

April 22, 2013

Sure, it is definitely a big stand alone package. Maybe it can provide some inspiration though, notably, the graphml output format is really nice and cross-library so maybe a simple first step is to write a simple I/O from labeled images to graphml? Guillaume Le 22/04/2013 10:58, Stéfan van der Walt a écrit : > On Mon, Apr 22, 2013 at 10:54 AM, Guillaume Gay > <guillaume(a)mitotic-machine.org> wrote: >> If you look for a numpy friendly gtraph library, I would strongly recommend >> graph-tool > Thanks for the pointer; graph-tools does look like a fantastic tool. > I don't think we're quite ready for the dependency on Boost, though. > > Stéfan >

3 2

Re: imageio progress
by Stéfan van der Walt April 22, 2013

April 22, 2013

Hi Juan On Sun, Apr 21, 2013 at 5:50 PM, Juan Nunez-Iglesias <jni.soma(a)gmail.com> wrote: > io.png.read() That is a very clean abstraction. It doesn't quite cover our use-case of supporting multiple readers for the same format, but then I also don't know if that is ideal. We could make these things explicit: import skimage.io.matplotlib as skio skio.imread(...) At the moment, we support either matplotlib, freeimage, pil, or whatever is around on the system to do the job. I guess the __init__ could try and import plugins until it finds one that works. Stéfan

1 0

Re: Morphological techniques
by Stéfan van der Walt April 22, 2013

April 22, 2013

On Mon, Apr 22, 2013 at 7:22 AM, Chintak Sheth <chintaksheth(a)gmail.com> wrote: > I was also thinking about having just the current convex_hull_image() with > an additional parameter, method. When method='union', i get the convex hull > of the entire image, and if method='object', i get the convex hull of > individual objects. Though this approach of defining an another function and > giving an additional option of returning convex hull of individual segmented > objects, seemed interesting. Also helps keep the code clean. In general, we prefer to use keywords as parameters that tweak the algorithm (not to switch out an entirely different algorithm). In this case, I think the preference will be for separate functions. Thanks Stéfan

1 0

Re: Describing superpixels
by Brickle Macho April 22, 2013

April 22, 2013

Hi StÃ¯Â¿Â½fan > If you had a mask for an individual superpixel, and indices into your > array, x, y, z, you can imagine finding the coordinates of all pixels > under that mask with > > x[mask], y[mask], z[mask] > > The mask you typically recover from a label image, so, e.g., mask = > (labels == 3). Thanks. > Now, the trickier problem is figuring out where, relative to other > super-pixels, this one is located. For that, it may be better to > represent the image as a graph, where each node represents a > super-pixel, and edges represent links to other super-pixels (in fact, I assumed/hoped there is some python based graph library that was numpy friendly. > this is something we should implement in scikit-image to make handling > labels easier). > > Would you be interested in collaborating on such a feature? Sure. I am still feeling my way, but am willing to contribute what every way I can. Regards, Michael. --

3 2