On Sun, Nov 7, 2010 at 2:24 PM, Chris Colbert <sccolbert@gmail.com> wrote:

The biggest reason for converging on a set of supported dtypes is for algorithms which are "by-and-large" dtype agnostic. e.g. color conversions, morphology, etc...

When implementing such things in Cython, you have to make a separate function for each dtype you wish to support, then dispatch appropriately.

Of course there will be cases where an algorithm expects/only operates on a specific dtype, and in those cases we can copy/cast. But I still think there should be an "official" set of supported dtypes. I think the reason float64 was chosen over float32 is because float64 is numpy's default floating point dtype. We could just as well use float32 in its stead if memory issues are of concern. I am agnostic on whether the our official float type is 32 or 64.

On Sun, Nov 7, 2010 at 12:32 PM, Maël Primet <mael.primet@gmail.com> wrote:
I agree with previous post,

usually, uint8 makes sense because it is the "usual image format", uint32 allows to handle image of labels (where there might be more than 255 labels), I don't really see an use for uint16 from what I've experienced (we might convert them to uint32, I'm not sure the x2 memory loss might be too problematic here), and float32 is often used. I more rarely use float64, except sometime inside an algorithm (rather than in input/output images).

For some algorithms, it makes sense to have a uint8 version, for some it doesn't. I'd say we should let the user make the conversions from/to the algorithm intended format himself, so he knows that the algorithm isn't intended for its original data format, and he takes special care in understanding why (rather than using an inapropriate algorithm and not worrying about the possible effects)

but we should clearly have conversion routines, that might also ensure that arrays are contiguous (to speed-up C/ Cython ), and possibly to ensure that we copy the array so we can modify it