RFR: IO cleanup

[Chris Colbert]

oh, and int16 is useful when doing derivative filtering on uint8 images, but
could as well be int32.

On Sun, Nov 7, 2010 at 2:24 PM, Chris Colbert <sccolbert at 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 at 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20101107/8c743c54/attachment.html>