[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