Closed robbwh closed 1 year ago
Try running nib-ls
on each of these files. The on-disk dtype of example4d.nii.gz is int16
. I suspect that tst2.nii
will be float32
or float64
.
When you create an image with a pre-existing header, the header will tell nibabel how the data should be written on-disk. Because you passed a header with an int16
data type, nibabel will find scale factors that allow you to cover the range of the data with 16 bits. Because there's no way to encode nan
as an integer, it gets converted to zero.
I would probably recommend explicitly setting your desired data type with img.set_data_dtype()
. If you're using a recent version of nibabel (>=4
), you can even set it at creation time with img = nb.Nifti1Image(data, affine, header, dtype='float32')
.
Ah okay makes sense. I thought it would be determined by the dtype of the array passed in Nifti1Image. But it makes sense that it is determined by the header. Yes setting dtype on save would be a good idea.
and yes, tst2.nii
does get saved as float64
.
Thank you
Here is a reproducible example using nibable.testing. Is this behavior expected? Personally, I feel like at least a warning should be generated.
nilearn correctly handles this situation