General suggestions about headers

[oesteban]

I'm finding real difficulties with files presenting non-diagonal sform matrices, they oftentimes mislead ANTs' initializations.

Since these matrices are only useful for mapping the data back to the scanner coordinates, I suggest here removing these matrices at the very beginning of the workflow, replacing them by the diagonal matrix of zooms.

We can have a final step where we set back the sform matrix (if necessary). For instance, if we report the preprocessed EPI on the T1w space, we would calculate the sform matrix from the T1w that would correspond to the preprocessed EPI. If the EPI is exactly in the grid of the T1w, then we set the sform of the T1w.

Taking care of the headers would also include issues like #384.

[oesteban]

I am currently doing this with this simple interface (please have a look if possible): https://github.com/poldracklab/fmriprep/blob/fieldmaps/fmriprep/interfaces/images.py#L254

Replaces the affine so that (0, 0, 0) [mm] falls in the center of the volume, and the matrix is diagonal.

[oesteban]

Looking closely at: nipy/nipype#1868

[effigies]

To be clear on this, by non-diagonal, do you mean oblique, or orthogonal but not RAS-oriented?

Do we have any existing datasets that are still affected by the issues you describe? Or was this resolved in working on the fieldmap workflows?

[oesteban]

• The problem is orthogonal but not RAS-oriented. Particularly when you plug into ANTs two different orientations. If both are the same it works even for not RAS-oriented.
• Datasets: I think I had this problem with ds054, but not sure now.

I have to say that the Affine initialization we are doing now is really robust against this problem.

[effigies]

Okay. I'd rather not scrap sforms unless we have no other option. Since the problem doesn't seem to be biting us at present, I'm going to close this for now, and we can reopen if it comes up again.