[Neuroimaging] Nibabel API change - always read as float

[Alexis Roche]

Hi Matthew,

I think that, if the data is int on disk with scale factors are (0,1), then
the intended dtype is more likely to be int than float - in the sense that
there is no obvious reason for casting the data to float, but it's more
efficient to keep it as int.

Alexis

On Mon, Jul 20, 2015 at 12:30 PM, Matthew Brett <matthew.brett at gmail.com>
wrote:

> Hi,
>
> On Sun, Jul 19, 2015 at 4:02 PM, Alexis Roche <alexis.roche at gmail.com>
> wrote:
> > Hi,
> >
> > Sorry for jumping late into this discussion.
> >
> > A case where I believe it would be confusing to have a float array by
> > default is resampling an image according to a spatial transform using
> cubic
> > spline or sinc interpolation (or any order>1 spline interpolation). While
> > such interpolation methods are arguably more accurate than trilinear
> > interpolation, they have the potential to produce negative intensities
> even
> > though the input image intensities are all positive and are expected to
> > remain positive after resampling. In such case, standard practice is to
> low
> > threshold interpolated values at zero, however that's something the user
> > would have to bear in mind (and be enforce himself) if dealing with a
> float
> > array as opposed to unsigned int.
> >
> > In that case, using the native image dtype would only help if it's
> unsigned
> > (which is not necessarily the case), but the point is: the user always
> has
> > to think about his/her dtype, there is no "universal" confusion-free
> dtype.
> >
> > When people ask me if there are drawbacks switching from matlab to
> python to
> > do image processing, I usually say that the only drawback I see is that
> you
> > have to be aware of your array type in python (as a consequence of using
> > numpy), which also has great advantages...
> >
> > Hence I am not very keen to get float arrays by default.
>
> Sorry to keep returning to this, but I feel the need to clarify.
>
> We all agree that it is good to give the user as much choice as
> possible about how the data gets loaded, whether scaled or unscaled,
> int or float.
>
> I think we all agree that, if there is an obvious intended in-memory
> dtype for the data, then nibabel should respect that.
>
> Unfortunately, neither the standard, nor standard practice, specifies
> what the *in-memory* dtype should be.
>
> We have the unfortunate current situation where the in-memory dtype
> depends on two details of the implementation, which are:
>
> * the convenient dtype to store the data on disk;
> *  whether the scalefactors are default or not.
>
> I think you could make the argument that the on-disk dtype is some
> indicator of the intended in-memory type, but I don't think you can
> make that argument for the scalefactors.
>
> If you agree with me, that the authors of NIfTI images do not
> generally intend the scalefactors to indicate the in-memory dtype,
> then my guess is you would probably agree that choosing a predictable
> default is better than the current situation - but please tell me if I
> am wrong about that.
>
> Cheers,
>
> Matthew
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging
>



-- 
Lead Clinical Research
Advanced Clinical Imaging Technology
Siemens/CHUV/EPFL
1015 Lausanne, Switzerland
Phone: +41 21 545 9972
https://sites.google.com/site/alexisroche
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150720/eb8ad1b7/attachment.html>