Boundary conditions

[theotherphil]

All the current filter operations treat pixels outside the input image as if we'd extended the boundary pixels indefinitely (i.e. padding "by continuity"). Affine transformations handle pixels whose pre-image is outside the input image by setting them to a user-provided default value.

The former is possibly limiting, and the latter is a bit clunky as you always have to provide a default even when you don't really care.

Come up with a sensible policy for handling boundary conditions and document it. Do we need to allow filter users to extend with zero/by symmetry/some other method?

[bvssvni]

I found something similar for OpenGL https://www.opengl.org/wiki/Common_Mistakes#Texture_edge_color_problem. It might be worth taking a look at how other APIs do it.

[theotherphil]

Thanks, I'll take a look. I know VLFeat allows zero or continuity padding. I've never looked into how this sort of thing is done in graphics libraries before.

[csheaff]

This has come up in working on #217. Regarding implementations for a custom border condition, I thought I'd mention two approaches that I've come across so far:

skimage._shared.interpolation.get_pixel3d - This is a function for retrieving a single pixel which takes into account the preferred boundary type. So in a given op, the border type is made use of when indexing the image, as indices exceeding the image size bounds can be passed to the function.

cv::copyMakeBorder - OpenCV's approach appears to be a padding of the image given the preferred border type prior to indexing the image.

I wonder if the skimage approach is cleaner, given that padding the image before ops requires efforts to avoid the added border when iterating across the image indices, which adds extra code and complication to every function needing a boundary condition. Although there might be speed considerations that I'm not aware of.