[Neuroimaging] Nibabel API change - always read as float
Brendan Moloney
moloney at ohsu.edu
Tue Jul 7 04:57:23 CEST 2015
> It sounds like consensus is rolling around to a dtype parameter, but I'm
> not entirely clear on what the semantics should be. The least surprising
> interpretation would be this:
>
> if dtype is not None:
> np.array_equal(dtype(img.get_data()), img.get_data(dtype=dtype))
I think it would be okay to raise an exception in 'get_data' where it may not
get raised in the 'dtype' function, but otherwise I agree the results should
match.
> However, if the type is clearly specified in the headers and not
> (uint16, m=1, b=0), would the dtype be ignored, or would we get
> dtype(img.get_data())? As noted, the former would be surprising, but the
> latter makes anything other than setting the default parameter to None
> impossible without making the default behavior even more surprising.
> Perhaps a dtype that conflicts with the header-specified type should
> cause an exception?
>
> Further, is the goal here to make this arbitrarily castable, or limited
> to float64 or the header-specified datatype, as in the original proposal
> of as_float?
These are good questions. My gut instinct is that we should raise an
exception on anything that would "hork up the data" as Nate put it.
So if you ask for int data when it should be a float (either due to the
storage dtype or due to the scale factors) that would cause an exception.
The grey areas I am less sure about. It is tempting to say float64 to
float32 casting should be allowed. I guess we could be clever about
things like int32 -> int16 (i.e. check the range).
One other thought. If you do want the native integer data (and it won't
raise an exception) you shouldn't have to know the number of bits.
Using 'np.int' and 'np.uint' for this purpose would cause the results to
differ from the 'dtype' function.
More information about the Neuroimaging
mailing list