
Indeed, marching cubes has anisotropic support presently. `random_walker` also does, though I think my original API for it is poor (only supports anisotropic `depth`, rather than true arbitrary anisotropy via `sampling`). I have an improvement/generalization PR for that in the works. I believe the most recent SLIC improvements also added a `sampling` parameter. On Friday, September 20, 2013 6:55:58 AM UTC-5, Almar Klein wrote:
On Thu, Sep 19, 2013 at 12:03 PM, Almar Klein <almar...@gmail.com<javascript:>>
wrote:
I suppose that the most important bit is that functions that support anisotropy should look whether a "sampling" attribute is present in the given array.
I don't think we currently have any of these, but for now we can probably include a `sampling` argument to functions that support it.
Mmm, you seem to be right, but you're *going* to :) The new marching cubes algorithm has a sampling argument, and I think Josh spoke about adding it so some morphological operators. I hope to do a PR on the MCP algorithm soon, which will add support for anisotropy as well.
I do not necessarily mean that a PointSet represents an image (although it
could), but more generally to for instance store the locations of detected feature points.
How do you think this would fit into the scope of image processing? (Asked out of curiosity, not at all to put the idea down.)
That's a good point. I think a PointSet class fits image processing because many image processing algorithms either accept or produce some form of locations or vectors. I would still call it "image processing" when you process the resulting locations/vectors. However, such algorithms probably fall out the scope of scikit-image.
So probably a better place for a PointSet class would be Scipy, but I have a feeling they would not be interested in including it.
I am not related to the development of scikit-image but I guess its goal
is to work on images in general and not get too specialised, for instance in Medical images.
I agree with that. I think that the only parameter of interest to scikit image is the "sampling" to deal with anisotropic arrays. So in that sense, it should be sufficient that sciki-image provides an Image class to which arbitrary attributes can be attached. Functions in scikit-image can the check if the array has a "sampling" attribute, and use it. If it returns an array with the same shape, it would be nice to also set the sampling on that.
May I ask: if you were to add sampling information and spatial
coordinates, such as an origin for the top-left pixel, how would you input that information into scikit-image, could you read it directly from the input files or would you need some user input?
I am not sure I understand. In most cases the attributes are added to the image (i.e. numpy array) when it is read.

On Sat, Sep 21, 2013 at 11:07 AM, Josh Warner <silvertrumpet999@gmail.com>wrote:
I believe the most recent SLIC improvements also added a `sampling` parameter.
I called it "spacing"... We should probably agree on a terminology library-wide. Incidentally, Josh, I called it "spacing" because of your SciPy talk. ;) For what it's worth, I still favour keeping all of these attributes separate and using vanilla numpy arrays, at the very least for images. For example, with the "spacing" parameter, I think it's much, much better for documentation and code readability to have it be an explicit input to the function, rather than an implied input via a field in an "Image" class.
participants (2)
-
Josh Warner
-
Juan Nunez-Iglesias