[Neuroimaging] Nibabel API change - always read as float

[Matthew Brett]

Hi,

On Sun, Jul 19, 2015 at 4:02 PM, Alexis Roche <alexis.roche at gmail.com> wrote:
> Hi,
>
> Sorry for jumping late into this discussion.
>
> A case where I believe it would be confusing to have a float array by
> default is resampling an image according to a spatial transform using cubic
> spline or sinc interpolation (or any order>1 spline interpolation). While
> such interpolation methods are arguably more accurate than trilinear
> interpolation, they have the potential to produce negative intensities even
> though the input image intensities are all positive and are expected to
> remain positive after resampling. In such case, standard practice is to low
> threshold interpolated values at zero, however that's something the user
> would have to bear in mind (and be enforce himself) if dealing with a float
> array as opposed to unsigned int.
>
> In that case, using the native image dtype would only help if it's unsigned
> (which is not necessarily the case), but the point is: the user always has
> to think about his/her dtype, there is no "universal" confusion-free dtype.
>
> When people ask me if there are drawbacks switching from matlab to python to
> do image processing, I usually say that the only drawback I see is that you
> have to be aware of your array type in python (as a consequence of using
> numpy), which also has great advantages...
>
> Hence I am not very keen to get float arrays by default.

Sorry to keep returning to this, but I feel the need to clarify.

We all agree that it is good to give the user as much choice as
possible about how the data gets loaded, whether scaled or unscaled,
int or float.

I think we all agree that, if there is an obvious intended in-memory
dtype for the data, then nibabel should respect that.

Unfortunately, neither the standard, nor standard practice, specifies
what the *in-memory* dtype should be.

We have the unfortunate current situation where the in-memory dtype
depends on two details of the implementation, which are:

* the convenient dtype to store the data on disk;
*  whether the scalefactors are default or not.

I think you could make the argument that the on-disk dtype is some
indicator of the intended in-memory type, but I don't think you can
make that argument for the scalefactors.

If you agree with me, that the authors of NIfTI images do not
generally intend the scalefactors to indicate the in-memory dtype,
then my guess is you would probably agree that choosing a predictable
default is better than the current situation - but please tell me if I
am wrong about that.

Cheers,

Matthew