Datatype issues from nilearn to niimath

[robbwh]

Hi,

I figured out how to fix this myself, but wanted to point out my issue/how I solved it.

I got a ventricle mask using math_img from nilearn:

t1seg = math_img("np.where(np.isin(img,[49,50,51,52]),1,0)",img=t1seg)

Then I wanted to get a distancemap from niimath (because fsl distancemap was very slow)
So I ran this:

niimath 209902_1.nii.gz -binv -edt 209902_1distance.nii.gz

which output this error message:
nifti_image_change_datatype: Unsupported datatype 1024 -> 16

So I changed my math_img command to:

t1seg = math_img("np.where(np.isin(img,[49,50,51,52]),np.int32(1),np.int32(0))",img=t1seg)

Which solved the issue.

This might be a nilearn math_img error and not an niimath error, but just wanted to post this in case anyone else had this issue.

[neurolabusc]

I have added support for DT_INT64 and DT_UINT64 datatypes. You can try this out with:

git clone --branch development https://github.com/rordenlab/niimath
cd ./niimath/src
make
./niimath

However, this treats the symptom, not the cause. Until this is resolved, you need to be extremely cautious about using nibabel. Perhaps @effigies has an update. I do not know how to escalate this issue, but I am concerned that these images are finding their way into archival datasets.

• Note that for your binary image, the uncompressed INT64 data requires 8 times the memory of the more common UINT8 datatype.
• Note that many tools popular in our field will fail to read this datatype including 3D slicer, SPM12, and ITK-based tools like ITK-snap. I did not test it, but I suspect that many popular ITK-based tools like ANTS will be similarly impacted. I suspect this data type will cause wide spread unintended consequences.