[Neuroimaging] Nibabel API change - always read as float

[Gael Varoquaux]

On Mon, Jul 06, 2015 at 10:19:07PM +0100, Matthew Brett wrote:
> > When you get some array, you need to be aware of what it is in order to work
> > with it. A mask or label image is not meant to be something on which you
> > perform algebraic manipulations. Sure, you can get it wrong if you don't
> > know what you're doing, but either this user has to learn it or he/she
> > should consider using higher level interfaces to work with images.

> `get_data()` was meant to be the higher level interface.

It's not: it's comming down to the numbers behind the data. When you go
down that far, you need to know what they mean.

Tools in dipy / nistats / nilearn that have a context of what is the
semantic meaning of the data are the higher-level building blocks.

> This argument would be a different one if it were always or even
> usually true that an integer stored data type and slope of 1 and
> intercept of 0 in a NIfTI signaled the intention that the data should
> be treated as integers when loaded.  However, that isn't even close to
> true.   Just for example, the large majority of functional images from
> the scanner are int datatype with slope, intercept of 1, 0, and we
> very rarely mean these to be treated as integers.

And we always convert data to float in functions that obviously work on
continous-valued data. But in a masking function, we would have to do
convert data the opposite way.

Where it get nasty is: what if the data has undergone a spatial
transformation? The original integer values are then interpolated to
intermediate values. What is then the right thing to do?

> I don't think it's sensible to try and educate the users out of this
> one, because I made this mistake, and I know numpy very well and wrote
> the relevant code in nibabel.

The way I avoid such errors is that I use higher-level abstraction.
That's something where we can win a battle. Any battle on low-level code
will be lost.

Gaël