[Neuroimaging] Nibabel API change - always read as float

Ben Cipollini bcipolli at ucsd.edu
Sun Apr 23 09:38:29 EDT 2017


Ah, sorry, my misunderstanding. Thanks for the clarification.

On Sun, Apr 23, 2017 at 6:34 AM, Satrajit Ghosh <satra at mit.edu> wrote:

> hi ben,
>
> i thought get_fdata() would always return float independent of whether the
> data needs to be scaled or not. so in that sense a little different from
> get_data, which would return datatype of disk if the data did not need to
> be scaled, but float otherwise.
>
> cheers,
>
> satra
>
> On Sun, Apr 23, 2017 at 9:25 AM, Ben Cipollini <bcipolli at ucsd.edu> wrote:
>
>> My understanding of the discussion above was that get_fdata() would lead
>> to the same behavior as get_data() now.
>>
>> On Sat, Apr 22, 2017 at 7:15 PM, Ariel Rokem <arokem at gmail.com> wrote:
>>
>>>
>>>
>>> On Tue, Apr 18, 2017 at 8:01 AM, Matthew Brett <matthew.brett at gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> On Wed, Jul 22, 2015 at 3:53 PM, Satrajit Ghosh <satra at mit.edu> wrote:
>>>> > hi matthew,
>>>> >
>>>> >> I'm not sure what you mean by 'did not interpret this' unless you are
>>>> >> agreeing with me that the niftiio library gives no clues as what the
>>>> >> intention for the in-memory type was.  If anything I think that
>>>> >> supports my reading that the authors had not considered the
>>>> >> interpretation of "scl_slope != 0 -> in-memory float".
>>>> >
>>>> >
>>>> > i simply meant they left any interpretation of how to scale or change
>>>> of
>>>> > in-memory data type to the end developer.
>>>> >
>>>> >> I can surely attach the raw scalefactors to the array proxy
>>>> (dataobj),
>>>> >
>>>> >
>>>> > that would be great
>>>> >
>>>> >>
>>>> >> but I think it's a terrible idea to use the scl_slope == 0 as an
>>>> >> indication for in-memory type, because it's not a convention that (as
>>>> >> far as I know) anyone else uses,
>>>> >
>>>> >
>>>> > all the examples of the code bases i provided in fact leave the
>>>> in-memory
>>>> > type to be the same as the native dtype for scalefactors (0, X) and
>>>> (1, 0).
>>>> > i agree, that this is an implementation of the standard as
>>>> interpreted by
>>>> > those developers, similar to present nibabel. i do agree that nifti
>>>> authors
>>>> > had nothing to say about such an interpretation.
>>>>
>>>> Following up on this one, much later - I have a new proposal, that I
>>>> have written up here:
>>>>
>>>> https://github.com/nipy/nibabel/wiki/BIAP8
>>>>
>>>> Shortest possible summary:
>>>>
>>>> * add "get_fdata" method to images, returning floating point data;
>>>> * deprecate "get_data" method in one year;
>>>> * raise error for "get_data" method in three years.
>>>>
>>>>
>>> Just to clarify: after the removal of "get_data", what would a user need
>>> to do to produce the current behavior of a `get_data()` call?
>>>
>>> Something like this was mentioned somewhere along this thread:
>>>
>>> data = img.dataobj.get_unscaled()
>>>
>>> Is that it?
>>>
>>> This has the advantage that older code using nibabel will not silently
>>>> return a different result, but will error, with an informative
>>>> message, for the foreseeable future.
>>>>
>>>> Any thoughts on this version?
>>>>
>>>> Cheers,
>>>>
>>>> Matthew
>>>> _______________________________________________
>>>> Neuroimaging mailing list
>>>> Neuroimaging at python.org
>>>> https://mail.python.org/mailman/listinfo/neuroimaging
>>>>
>>>
>>>
>>> _______________________________________________
>>> Neuroimaging mailing list
>>> Neuroimaging at python.org
>>> https://mail.python.org/mailman/listinfo/neuroimaging
>>>
>>>
>>
>> _______________________________________________
>> Neuroimaging mailing list
>> Neuroimaging at python.org
>> https://mail.python.org/mailman/listinfo/neuroimaging
>>
>>
>
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20170423/66ec8244/attachment.html>


More information about the Neuroimaging mailing list