nd image neighbor-finding

[Josh Warner]

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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20130813/04f6cdf4/attachment.html>