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

Hi Almar

On Thu, Sep 19, 2013 at 11:36 AM, Almar Klein <almar.klein@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.