[Neuroimaging] Nibabel API change - always read as float

[Bob Dougherty]

Hi All,

I've been silently enjoying this thread, and now that the dust appears 
to be settling I'll offer my humble opinion:

1. I definitely like the dtype option over the other alternatives proposed

2. I agree that the choice of default behavior is challenging, and want 
to reinforce what Brendan says here-- nifti is a bit messy and there is 
very often no clear answer as to what the returned type should be. I 
guess I am also slowly coming around to float64 as the default, and if 
you need something else you can use the dtype option.

3. and just to be nit-picky... the raw MR k-space data are actually 
16-bit integers (that's what the ADCs return). So there is some logic 
behind keeping MR data represented with 16-bit integers, even after the 
image reconstruction (which is indeed a floating-point computation).

cheers,
bob

On 07/06/2015 01:50 PM, Brendan Moloney wrote:
> > Well, unless I am mistaken, there is no ambiguity in the
> > datatype of a binary file.
>
> I guess you mean a .npy file?  A plain binary file is nothing
> but ambiguity.
>
> > Plus,  numpy does not enforce anything, it is just a
> > default value.
>
> The latest proposition that I am running with is to include
> a 'dtype' keyword for nibabel.load. I guess Matthew would
> argue the default value should be float, and I am really
> starting to agree with that point of view.
>
> > Using np.genfromtxt(dtype=None), and you get a more
> > logical behavior.
>
> $ cat testfile
> 1 2 3 4 5
> 1 2.2 3 4 5
>
> $ python -c 'from numpy import genfromtxt ; print 
> genfromtxt("testfile", dtype=None)'
> [(1, 2.0, 3, 4, 5) (1, 2.2000000000000002, 3, 4, 5)]
>
> I don't find this behavior to be particularly logical. I guess
> there is a reason the default is 'float'.
>
> > Whatever you do, if you load a npy file using np.load,
> > it will always be of the type saved in the first place.
>
> Because it is a nice clean file format they control entirely.
>
>     > Also, numpy does not have to deal with the weirdness of using
>     > integers plus scale factors to represent floating point data.
>
>
> > Well, in that case, why not adding a dtype value in the header ?
>
> Because nibabel tries to load a bunch of formats that we have little
> to no control over. Even in Nifti files where there is an "intent code"
> that could be set to NIFTI_INTENT_LABEL for label files, I don't
> think any software actually does this. Even if some software does,
> we can't rely on it.
>
>     > Even without scale factors the data in an
>     > MRI isn't inherently integer data, it was just quantized that
>     way for
>     > efficiency.
>
>
> > Except that Nifti can store other things than MRI data (such as masks,
> > labels, or any voxel-related value).
>
> I clearly acknowledged that in the next paragraph (which you trimmed),
> and you don't address the fact that is almost always obvious from
> context if the file is a mask/label. It isn't always obvious if an image
> file is going to be float or not.
>
> -Brendan
>
>
>
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging

-- 
Robert F. Dougherty, PhD
Research Director
Stanford Center for Cognitive and Neurobiological Imaging
70 Jordan Hall  *  Stanford CA 94305  *  650-725-0051
http://www.stanford.edu/~bobd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150706/acbeb126/attachment-0001.html>