ndarray subclasses

[Almar Klein]

On 19 September 2013 11:41, Stéfan van der Walt <stefan at sun.ac.za> wrote:

> Hi Almar
>
> On Thu, Sep 19, 2013 at 11:36 AM, Almar Klein <almar.klein at gmail.com>
> wrote:
> > Skimage also has the Image class (that inherits from np.ndarray), which I
> > believe is mostly there to make the image be shown as an image in IPython
> > notebook. What about taking this idea a bit further? In particular, I am
> > thinking about two things:
> >
> > 1) Allowing extra attributes for the Image class, like "sampling" that
> > specifies the distance between the pixels. This attribute can then be
> used
> > by algorithms to take anisotropy into account, and visualization toolkits
> > could use it to scale the image in the correct way automatically. This
> may
> > not seem a very common use case for 2D images, but 3D data is usually not
> > isotropic.
>
> We tried making this the default output of imread, but it caused some
> problems (e.g. when you slice out a scalar, or sum, you get an Image
> object out!), so we're back to vanilla arrays.


I've had the same problem with my own "Image" class. You can solve this
pretty well by overloading __getitem__ and __array_wrap__. A small example:
https://gist.github.com/almarklein/6621363


That said, the Image
> object is still quite useful.  The Image class has a dictionary
> container for adding any type of meta-data you want (e.g., origin,
> sampling distance, etc.) so I don't know if it is necessary to
> explicitly specify what those fields should be.
>

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.


> 2) Using a PointSet class to represent numpy arrays that are point sets or
> > vector sets. Also such a class can make working with point data much
> easier,
> > both in internal algorithms, and for the end-user.
> >
> > An example class can be seen here:
> > https://gist.github.com/almarklein/6620956 it allow things like
> > appending/removing/inserting/
> popping individual points, and calculating
> > things like normals, angles, distances, etc.
>
> In this case, I see an argument for having such a class, since it
> behaves differently from a traditional image, and may need to be
> resampled to a regular grid, etc.
>

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.


The computation of normals, angles,
> etc. could be be utility functions outside the class (I guess I'm a
> minimalist when it comes to class design).
>

You're probably be right about that. The most important bit is the
manipulation of individual points inside the pointset.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20130919/d69dbd48/attachment.html>