<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
</head>
<body ocsi="0" fpstyle="1">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">> Well, unless I am mistaken, there is no ambiguity in the
<br>
> datatype of a binary file. <br>
<br>
I guess you mean a .npy file? A plain binary file is nothing <br>
but ambiguity.<br>
<br>
> Plus, numpy does not enforce anything, it is just a <br>
> default value. <br>
<br>
The latest proposition that I am running with is to include <br>
a 'dtype' keyword for nibabel.load. I guess Matthew would <br>
argue the default value should be float, and I am really <br>
starting to agree with that point of view.<br>
<br>
> Using np.genfromtxt(dtype=None), and you get a more <br>
> logical behavior.<br>
<br>
$ cat testfile<br>
1 2 3 4 5<br>
1 2.2 3 4 5<br>
<br>
$ python -c 'from numpy import genfromtxt ; print genfromtxt("testfile", dtype=None)'<br>
[(1, 2.0, 3, 4, 5) (1, 2.2000000000000002, 3, 4, 5)]<br>
<br>
I don't find this behavior to be particularly logical. I guess <br>
there is a reason the default is 'float'.<br>
<br>
> Whatever you do, if you load a npy file using np.load, <br>
> it will always be of the type saved in the first place.<br>
<br>
Because it is a nice clean file format they control entirely.<br>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">
<div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
> Also, numpy does not have to deal with the weirdness of using<br>
> integers plus scale factors to represent floating point data.<br>
</blockquote>
<span class="im"><br>
</span></div>
<div>> Well, in that case, why not adding a dtype value in the header ?<br>
<br>
Because nibabel tries to load a bunch of formats that we have little <br>
to no control over. Even in Nifti files where there is an "intent code" <br>
that could be set to NIFTI_INTENT_LABEL for label files, I don't<br>
think any software actually does this. Even if some software does, <br>
we can't rely on it.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
> Even without scale factors the data in an<br>
> MRI isn't inherently integer data, it was just quantized that way for<br>
> efficiency.<br>
</blockquote>
<div><br>
</div>
<div>> Except that Nifti can store other things than MRI data (such as masks, <br>
> labels, or any voxel-related value).<br>
<br>
I clearly acknowledged that in the next paragraph (which you trimmed), <br>
and you don't address the fact that is almost always obvious from <br>
context if the file is a mask/label. It isn't always obvious if an image <br>
file is going to be float or not.<br>
<br>
-Brendan<br>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>