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@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@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.