Loading 4D MINC images

[neurolabusc]

nibabel does a great job converting 3D MINC images. However, it does have an odd feature with 4D images - the MINC images tend to store time as the first dimension. In contrast, formats like NIfTI reserve the first three dimensions for spatial (xyz). In practicem this means 4D MINC images are treated as txyz instead of xyzt. Sample images and conversion scripts showing the performance of nibabel versus mnc2nii are here. Note sure if this is a weakness of nibabel per se, or whether the file saving of nibabel should swizzle order. Does nibable encode which dimension is spatial?

[effigies]

Does nibable encode which dimension is spatial?

Not really. This has been a bit of a long-standing wart:

• We need to sort out axis labeling soon #412

There is some code in the minc1.Minc1File and minc2.Minc2File classes to identify dimensions, but it never gets exposed to the SpatialImage subclasses Minc1Image and Minc2Image.

There's been very little MINC expertise among nibabel contributors to date, so this has been stalled. If someone is interested in taking this on, I can definitely discuss a plan and review PRs. That said, it's not clear to me that the juice will be worth the squeeze to stay in the current object model.

@matthew-brett started some exploration of using nibabel as an I/O layer and targeting xarray objects in https://github.com/matthew-brett/xibabel (docs: https://matthew-brett.github.io/xibabel/). Since MINC2 is already HDF5, it might be even simpler to target an xarray object efficiently.

Mapping metadata between formats will still be a problem, but the axis mapping could be trivial to resolve in that framework.

[neurolabusc]

@effigies thanks for the quick response. The MINC files do explicitly report the order of the dimensions. You can see this with nibabel by adding a print() command here

        print(dimorder)
        return dimorder.split(',')[: len(var.shape)]

For the sample 4D MNC files I provide, this prints the dimension order, allowing you to distinguish the time dimension from the spatial dimensions for the axial, coronal and sagittal images:

(py3) mnc2nii.py % python mnc2nii.py ./In/ax2.mnc
time,zspace,yspace,xspace
(py3) mnc2nii.py % python mnc2nii.py ./In/cor2.mnc
time,yspace,zspace,xspace
(py3) mnc2nii.py % python mnc2nii.py ./In/sag2.mnc
time,xspace,zspace,yspace

If it helps, I wrote a TypeScript MINC to NIFTI converter for the command line (node) and web pages (NiiVue) that does create NIfTI files where the spatial dimensions are the first three NIfTI dimensions. I do not think my code handles all the possible orderings, only the ones seen in the wild. I actually do not swizzle the voxel data as in all cases I have seen and created MINC lists time as the first dimorder (with MINC, dimensions are listed from slowest to fastest changing, reverse of NIfTI's i,j,k,... and therefore the time dimension does not need to be swizzled). It does leverage nibabel's affine conversion which is much easier to follow than the reference mnc2nii (and has proved robust in all my tests). So in my experience, nibabel handles the hard stuff perfectly and more elegantly than the reference implementation. The missing link is the simple stuff of handling 4D volumes.