Mailman 3 August 2013 - scikit-image

EuroSciPy sprint
by Stéfan van der Walt Aug. 27, 2013

Aug. 27, 2013

Hi everyone, I want to send a big shout-out to everyone who sprinted on skimage at EuroSciPy2013! You guys did a great job, and it was a lot of fun watching all the pull requests and comments fly by. Emmanuelle, how about we do a short blog post on the event? I can combine it with the results of the US sprint that I still have on the shelf. Stéfan

1 0

Re: Error importing feature: Issue with match_template function?
by Payal Gupta Aug. 27, 2013

Aug. 27, 2013

hello.... i have same problem please someone solve this problem... how i import scikit image library ?? On Thursday, November 29, 2012 10:31:19 PM UTC+5:30, Marianne Corvellec wrote: > > Dear skimage people, > > I am having an Import Error when I try to import feature, namely: > > In [28]: from skimage import feature > --------------------------------------------------------------------------- > ImportError Traceback (most recent call last) > > /home/[...]/<ipython console> in <module>() > > /home/[...]/skimage/feature/__init__.py in <module>() > 1 from ._hog import hog > 2 from .texture import greycomatrix, greycoprops, > local_binary_pattern > 3 from .peak import peak_local_max > 4 from ._harris import harris > ----> 5 from .template import match_template > > /home/[...]/skimage/feature/template.py in <module>() > 2 """ > 3 import numpy as np > ----> 4 from . import _template > 5 > 6 > > ImportError: cannot import name _template > > I saw that the function `match_template` is defined in both template.py > and _template.pyx: > isn't that wrong--and/or related to the import error? > > I am running this version: > In [27]: skimage.__version__ > Out[27]: '0.7dev' > > How do you guys import feature? > > Thanks, > Marianne >

2 1

Re: New PEP8 recommendations
by Johannes Schönberger Aug. 26, 2013

Aug. 26, 2013

I guess someone will update the pep8 package soon... ? Johannes Schönberger Am 26.08.2013 um 21:48 schrieb "Stéfan van der Walt" <stefan(a)sun.ac.za>: > On Mon, Aug 26, 2013 at 9:45 PM, Johannes Schönberger <jsch(a)demuc.de> wrote: >> I think I sent this link a couple of weeks ago already to the list :-) > > Reinforcement learning! > > Now, if we can get the PEP checking tools to be quieter... > > 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: New PEP8 recommendations
by Johannes Schönberger Aug. 26, 2013

Aug. 26, 2013

Hi Stefan, I think I sent this link a couple of weeks ago already to the list :-) At least we can be a bit less pedantic about the coding style now ;-) Johannes Schönberger Am 26.08.2013 um 21:43 schrieb "Stéfan van der Walt" <stefan(a)sun.ac.za>: > http://www.python.org/dev/peps/pep-0008/#other-recommendations > > I knew we were onto something with our spacing of those exponents :) > > -- > 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. >

2 1

New PEP8 recommendations
by Stéfan van der Walt Aug. 26, 2013

Aug. 26, 2013

http://www.python.org/dev/peps/pep-0008/#other-recommendations I knew we were onto something with our spacing of those exponents :)

1 0

HOG
by Jean K Aug. 22, 2013

Aug. 22, 2013

Hello, I am new to the scikit-image, and interested in using HOG. However, the one which is implemented doesn't seem to give as good results as expected. As a possible explanation I think mainly of 2 reasons: 1) the way of computing the gradients ( if I'm not mistaking, you use a [-1, 1] filter when they use a centered one [-1, 0, 1]. 2) They use tri-linear interpolation when here the you seem to use hard binning. Does this make sense or am I missing something? Also, I tried to write another version, trying to stick as much as possible to Dalal&Triggs version, although I don't really know how to assess the results it produces. Would that be of interest? Cheers, Jean

3 7

Re: nd image neighbor-finding
by Josh Warner Aug. 14, 2013

Aug. 14, 2013

I‘m +1 on all of Jaime’s suggestions. Also, for #3 there is no need to reinvent the wheel - I'm pretty sure every one of those padding options, and more, are supported by skimage.util.pad. Depending on how you implement the function, you may need to run np.ascontiguousarray on the output of skimage.util.pad. Josh On Tuesday, August 13, 2013 12:04:51 AM UTC-5, Juan Nunez-Iglesias wrote: Hi everyone, > > I'm trying to design an interface for an nD "get_neighbors(idxs, ar, > conn)" function: given one or more indices into an ndarray `ar`, and a > connectivity (integer in {1, ..., ar.ndim}), return the indices of its > neighbors. There's multiple design decisions to be made: > > 1. Work with linearized or regular indices? In the past I've used > linearized indices because they are much easier to treat generally in an nd > setting. However, most users probably don't want to deal with converting to > and from linear indices (though np has a function to convert to and from > linear indices). Perhaps more relevant though, linear indices get very very > tricky once you stop dealing with contiguous arrays. In fact, I'm not quite > sure I'm up to the task. ;) > > 2. If we want to work with regular indices, what should be the input > format? There's lots of options: a list of tuples? a tuple of np.arrays of > ints, similar to what numpy expects for __getitem__? a 2D array of ints, > similar to the "coords" format used throughout ndimage? > > 3. What should the return format be? The problem is that edge pixels have > fewer neighbors than non-edge ones. So, anything like a 2D ndarray is > pretty much out of the question, *unless* we also return a matching array > called something like `valid` that shows directions where the > neighbor-finding has hit an edge. This is of course all sidestepped if we > only allow one index to be passed, but that forgoes a lot of possible saved > efficiency by not making lots of python function calls. > > In the past, I've sidestepped the whole issue of the boundaries by padding > my array and never asking for the neighbors of something in the "pad" area, > but I don't think that's viable for a public-facing function. =) > > I'll be very interested to hear what everyone has to say about this...! > Thanks! > > Juan. > >

2 1

Re: nd image neighbor-finding
by Jaime Fernández del Río Aug. 13, 2013

Aug. 13, 2013

Answers from a heavy numpy user with little experience with scikits-image, so they may not be consistent with general API rules: 1. Either accept both, with a keyword argument, e.g. flat_idx=True or ravel_idx=True, or have two functions doing the exact same thing, one for each type of index. I prefer the former than the latter. 2. Whatever the input, accept anything array-like. If you are dealing with multi-indices, either require that the actual dimensions are along the last axis, or have an axis keyword argument that specifies it. It may not be necessary, but it may make users life easier if you do not force a specific shape like (r,d) for r indices with d dimensions, but something like (r, s, d) is also accepted, and produces a return of e.g. shape (n,r,s,d), where n is the number of neighbors. 3. Anything returned that is not an array is going to be a big performance hit... You could adopt a modified version of what scipy.ndimage does for similar situations: have a mode keyword argument, e.g. convolve accepts {‘reflect’,’constant’,’nearest’,’mirror’, ‘wrap’}, a 'constant' mode could be used to mark (by default) indices out of bounds with -1, which is equivalent to returning a validity mask, specially if you roll an example using np.any in the docstring, 'mirror' or 'reflect' are good options if you need a list of neighbors but don't mind repetitions, and I very often work with images that are tiled, so 'warp' would be a good thing also. Jaime On Mon, Aug 12, 2013 at 10:04 PM, Juan Nunez-Iglesias <jni.soma(a)gmail.com>wrote: > Hi everyone, > > I'm trying to design an interface for an nD "get_neighbors(idxs, ar, > conn)" function: given one or more indices into an ndarray `ar`, and a > connectivity (integer in {1, ..., ar.ndim}), return the indices of its > neighbors. There's multiple design decisions to be made: > > 1. Work with linearized or regular indices? In the past I've used > linearized indices because they are much easier to treat generally in an nd > setting. However, most users probably don't want to deal with converting to > and from linear indices (though np has a function to convert to and from > linear indices). Perhaps more relevant though, linear indices get very very > tricky once you stop dealing with contiguous arrays. In fact, I'm not quite > sure I'm up to the task. ;) > > 2. If we want to work with regular indices, what should be the input > format? There's lots of options: a list of tuples? a tuple of np.arrays of > ints, similar to what numpy expects for __getitem__? a 2D array of ints, > similar to the "coords" format used throughout ndimage? > > 3. What should the return format be? The problem is that edge pixels have > fewer neighbors than non-edge ones. So, anything like a 2D ndarray is > pretty much out of the question, *unless* we also return a matching array > called something like `valid` that shows directions where the > neighbor-finding has hit an edge. This is of course all sidestepped if we > only allow one index to be passed, but that forgoes a lot of possible saved > efficiency by not making lots of python function calls. > > In the past, I've sidestepped the whole issue of the boundaries by padding > my array and never asking for the neighbors of something in the "pad" area, > but I don't think that's viable for a public-facing function. =) > > I'll be very interested to hear what everyone has to say about this...! > Thanks! > > Juan. > > -- > 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. > -- (\__/) ( O.o) ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial.

1 0

nd image neighbor-finding
by Juan Nunez-Iglesias Aug. 13, 2013

Aug. 13, 2013

Hi everyone, I'm trying to design an interface for an nD "get_neighbors(idxs, ar, conn)" function: given one or more indices into an ndarray `ar`, and a connectivity (integer in {1, ..., ar.ndim}), return the indices of its neighbors. There's multiple design decisions to be made: 1. Work with linearized or regular indices? In the past I've used linearized indices because they are much easier to treat generally in an nd setting. However, most users probably don't want to deal with converting to and from linear indices (though np has a function to convert to and from linear indices). Perhaps more relevant though, linear indices get very very tricky once you stop dealing with contiguous arrays. In fact, I'm not quite sure I'm up to the task. ;) 2. If we want to work with regular indices, what should be the input format? There's lots of options: a list of tuples? a tuple of np.arrays of ints, similar to what numpy expects for __getitem__? a 2D array of ints, similar to the "coords" format used throughout ndimage? 3. What should the return format be? The problem is that edge pixels have fewer neighbors than non-edge ones. So, anything like a 2D ndarray is pretty much out of the question, *unless* we also return a matching array called something like `valid` that shows directions where the neighbor-finding has hit an edge. This is of course all sidestepped if we only allow one index to be passed, but that forgoes a lot of possible saved efficiency by not making lots of python function calls. In the past, I've sidestepped the whole issue of the boundaries by padding my array and never asking for the neighbors of something in the "pad" area, but I don't think that's viable for a public-facing function. =) I'll be very interested to hear what everyone has to say about this...! Thanks! Juan.

1 0

integral image for each depth in a three dimensional array
by masa Aug. 6, 2013

Aug. 6, 2013

Hi all, I want to calculate integral images for each depth in a three dimensional array. My code is something like this: ret = np.empty(height, width, depth) int_imgs = [integral_image(image[:,:,i]) for i in range(depth)] for i in range(depth): ret[:,:,i] = int_imgs[i] Is there better way to do this? Thanks, masa

3 5