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.

[neurolabusc]

I have created a kludge to handle this with my Python nibabel wrapper mnc2nii.py, and I am closing this issue. However, I do think it would be more elegant if minc2.py would be updated so that get_dimensions() could be exposed as part of the public API vs. only an internal method (those prefixed with _). This would allow one to determine the order of the spatial versus temporal dimensions. My kludge simply recapitulates this behavior in the wrapper if the image is 4D.

I am closing this issue, as it does not seem a format with heavy active use, and my kludge works for archival data. However, happy to revisit if one of the nibabel developers wants to implement changes.

[effigies]

I would be okay with exposing the details. The main thing, I think, is that we would need to keep the mincfile object around and proxy calls to it. There's a question of whether to wrap that inside Minc[12]Header or just Minc[12]Image, but I'd be inclined to defer to anyone willing to put in the time.