Missing orientation information from image header - fmriprep fixing it correctly?

Hi there,

I’m running FMRIPREP on a fMRI task dataset, it runs through and the report and output looks sensible, except that I get a warning on missing orientation information. I’m a bit confused with the terminology and names (sform, qform) and what fMRIPREP does to fix it, so would appreciate help on whether what I have is fine or not.

Warning message from report:

WARNING - Missing orientation information

FMRIPREP could not retrieve orientation information from the image header. The qform and sform matrices have been set to a default, LAS-oriented affine. Analyses of this dataset MAY BE INVALID.

The message is between “## Reports for Task” and “### Fieldmap to EPI registration”.

Using fslhd to check header information of the epi file before and after fmriprep shows this (copied a chunk from the output):

BEFORE fmriprep

qform_name Unknown
qform_code 0
qto_xyz:1 -3.000000 0.000000 -0.000000 0.000000
qto_xyz:2 0.000000 2.987174 -0.277111 0.000000
qto_xyz:3 0.000000 0.277111 2.987174 0.000000
qto_xyz:4 0.000000 0.000000 0.000000 1.000000
qform_xorient Right-to-Left
qform_yorient Posterior-to-Anterior
qform_zorient Inferior-to-Superior
sform_name Unknown
sform_code 0
sto_xyz:1 -3.000000 0.000000 -0.000000 96.000000
sto_xyz:2 -0.000000 2.987170 -0.277112 -83.148903
sto_xyz:3 0.000000 0.277112 2.987170 -44.335602
sto_xyz:4 0.000000 0.000000 0.000000 1.000000
sform_xorient Right-to-Left
sform_yorient Posterior-to-Anterior
sform_zorient Inferior-to-Superior
file_type NIFTI-1+

AFTER fmriprep

qform_name Aligned Anat
qform_code 2
qto_xyz:1 3.000000 0.000000 0.000000 -96.000000
qto_xyz:2 0.000000 3.000000 0.000000 -132.000000
qto_xyz:3 0.000000 0.000000 3.000000 -78.000000
qto_xyz:4 0.000000 0.000000 0.000000 1.000000
qform_xorient Left-to-Right
qform_yorient Posterior-to-Anterior
qform_zorient Inferior-to-Superior
sform_name Aligned Anat
sform_code 2
sto_xyz:1 3.000000 0.000000 0.000000 -96.000000
sto_xyz:2 0.000000 3.000000 0.000000 -132.000000
sto_xyz:3 0.000000 0.000000 3.000000 -78.000000
sto_xyz:4 0.000000 0.000000 0.000000 1.000000
sform_xorient Left-to-Right
sform_yorient Posterior-to-Anterior
sform_zorient Inferior-to-Superior
file_type NIFTI-1+
file_code 1
descrip xform matrices modified by FixHeaderApplyTransforms (niworkflows v0.5.1).

Thank you!

Without original orientation information, it’s impossible to say, which is why we produce the warning. At this point, it’s up to the user to verify. If you’re confident the original images had 3mm^3 voxels in LAS orientation, then the outputs are fine.

For more information on qforms and sforms, see Working with NIfTI images - The NIfTI affines. If you know that the original affine for certain, you can add it and set the qform or sform matrices and codes manually, e.g. in nibabel:

import nibabel as nb

affine = [[a, b, c, d],
          [e, f, g, h],
          [i, j, k, l],
          [0, 0, 0, 1]]

img = nb.load(fname)
img.header.set_qform(affine, 1)
img.header.set_sform(affine, 1)
img.affine = affine


The best option, of course, is to re-convert from DICOMs using a tool that preserves metadata, such as dcm2niix or heudiconv.

Thanks for this. I checked the header info of the original niffti image using: fslorient -getorient, which gave RADIOLOGICAL. Which I checked is the same as LAS.

I actually did use dcm2niix, and the json files passed the BIDS test, so not sure why it couldn’t find the orientation information (since it looks like it exists in the original nifti).

FSL gives you the default interpretation of an image with invalid affine codes, which I believe corresponds to the old ANALYZE convention. Nibabel (and thus we) also follow that interpretation, so at least it will be consistent. However, I would not use the output of fslorient as evidence that the interpretation is correct.

The qform and sform matrices are consistent and non-trivial, which does seem like a decent indication that your affine is what is indicated, though I would also check those values with nibabel (again, FSL fills in missing data with its own defaults, so it’s worth being a little skeptical):

import nibabel as nb

img = nb.load(fname)

Assuming that it is one of the affines indicated by fslhd, those are LAS affines, so that’s consistent with the FSL/fMRIPrep interepretations.

It is somewhat troubling, however, that your dcm2niix conversions don’t produce valid NIfTI affine codes. @Chris_Rorden Do you know of cases where that’s likely to happen?

I would check the providence of the NIfTI images. Make sure you are using a recent version of dcm2niix and check the output for error messages. Provided a valid DICOM image, dcm2niix will set both the qform_name and sform_name to Scanner Anat. Given that these are set to Unknown, I think that fslhd is just using the pixdims to infer spatial orientation. I would be particularly concerned with left-right flips due to the symmetry of the human brain. If you use a fiducial marker (e.g. a vitamin E capsule on the left temple is easy to see on the anatomical scan) you should work this out. Regardless, the Unknown value is not the typical output of dcm2niix and suggests a catastrophic failure (reported in the output of dcm2niix) or the fact that some other tool touched this data. The raw output of dcm2niix should look something like this with fslhd:

qform_name     Scanner Anat
qform_code     1
qto_xyz:1      0.999315  0.035794  0.005047  -88.121933
qto_xyz:2      -0.036643  0.975905  -0.001891  -96.514191
qto_xyz:3      -0.005236  0.001704  0.976548  -120.231659
qto_xyz:4      0.000000  0.000000  0.000000  1.000000
qform_xorient  Left-to-Right
qform_yorient  Posterior-to-Anterior
qform_zorient  Inferior-to-Superior
sform_name     Scanner Anat
sform_code     1
sto_xyz:1      0.999314  0.035794  0.005047  -88.121933
sto_xyz:2      -0.036643  0.975905  -0.001891  -96.514191
sto_xyz:3      -0.005236  0.001704  0.976548  -120.231659
sto_xyz:4      0.000000  0.000000  0.000000  1.000000
1 Like

@effigies I suspect the images with s/qform_name of Unknown were either not created by dcm2niix or were manipulated after conversion by dcm2niix. The only situation I can think of where dcm2niix might do this is when providing DICOM images without tags 0020,0032 and 0020,0037. These are Type 1 tags, so these are not valid DICOMs, and dcm2niix will report an error. The common instance of this situation is some Siemens derived images - e.g. colored fractional anisotropy maps. These derived images have no place in scientific analyses: one can generate much better derived images after processing the raw data (de-noise, de-Gibbs, TOPUP, eddy).

I went back to the original files and turns out the output from dcm2niix had the correct and relevant info.

The root of the problem was that I wanted to change the header info (TR time) using the fslhd and fslcreatehd commands, and for some reason it doesn’t write the sform and qform name correctly, and I couldn’t figure out how to retain this info. However, much thanks to @effigies or pointing me to the link ‘working with nifti images’ - I was able to edit the header using python instead! Thanks!

Apologies, it wasn’t an fmriprep problem nor a dcm2niix problem!