Mapping between MNI152NLin6Asym ijk-coordinates and CIFTI row indices differs from HCP

[madisoth]

What happened?

In HCP 91k CIFTIs, within each subcortical structure, the mapping from ijk-coordinates to CIFTI row indices is basically a nested loop with the CIFTI row index being incrementing along with i, then j, then k (i.e. nested loop going k, j, i from outer to inner). NiWorkflows is incrementing along k, then j, then i. Since the ijk to CIFTI row mapping differs, NiWorkflows-generated CIFTI subcortical data are spatially transposed when mapped onto the "canonical" HCP 91k grayordinates template.

What command did you use?

/opt/conda/envs/fmriprep/bin/fmriprep --fs-license-file /license.txt --resource-monitor --project-goodvoxels --omp-nthreads 3 --cifti-output 91k -vv -w /wd /bids_dir /output_dir participant

What version of the software are you running?

fMRIPrep 23.1.1

How are you running this software?

Singularity

Is your data BIDS valid?

Yes

Are you reusing any previously computed results?

No

Please copy and paste any relevant log output.

No response

Additional information / screenshots

No response

[effigies]

This is a little strange, as the CIFTI-2 header is supposed to explicitly list the voxel indices so that ordering does not matter. Is there a display problem, or is the problem that the BrianModelAxis is not identical to an HCP-generated one, and so the data arrays are not directly comparable without reordering voxels?

[effigies]

@madisoth Can you patch in niworkflows 1.8.1 and retest on affected data? If you're using fmriprep-docker, you can use --patch niworkflows=.... Can come up with a Singularity bind, if you don't already have a process there.

[tsalo]

@madisoth did the fix in #815 end up solving the problem?

[tsalo]

@madisoth I saw a post of yours on basecamp where it sounds like #815 addressed your problem. Is that correct?

[amirhusseinab]

Can I ask a quick question? Was this CIFTI-indexing also a problem in the previous (20.x.x) versions as well?

[effigies]

Yes.