Faulty NIfTI-conversion of Philips data, how to re-manipulate the dimensions?

1

I have some Philips data (7T) which tricks dcm2niix in the DICOM-to-NIfTI-conversion.
This is a sag MP2RAGE image that is reconstructed on the scanner. When converting it, the SS-direction along the 4th dim but corrupts the voxel sizes.

************************************************
Image name:          "sub-7T049S02_acq-mp2rage_run-1_UNIT1.nii.gz"
************************************************
  Dimensions:        1 x 352 x 352 x 257
  Voxel size:        0.7 x 0.639788 x 0.639788 x 0.0068
  Data strides:      [ 4 -1 2 3 ]
  Format:            NIfTI-1.1 (GZip compressed)
  Data type:         signed 16 bit integer (little endian)
  Intensity scaling: offset = -511.87509155273438, multiplier = 0.25
  Transform:               0.9997     0.00486     0.02455      0.2514
                        1.397e-09       0.981     -0.1942      -86.44
                         -0.02503      0.1941      0.9807      -133.9
  comments:          TE=2.4;Time=103920.070

image
image707×612 157 KB

Well, the same goes for mrconvert directly on the DICOM

mrconvert s1309_WIP_-_imag - | mrinfo -
mrconvert: [done] scanning DICOM folder "s1309_WIP_-_imag"
mrconvert: [100%] reading DICOM series "WIP - imag"
mrconvert: [100%] copying from "7T049109 (20211014) [MR] WIP - imag" to "/tmp/mrtrix-tmp-k2y2yl.mif"
************************************************
Image name:          "/tmp/mrtrix-tmp-k2y2yl.mif"
************************************************
  Dimensions:        1 x 352 x 352 x 257
  Voxel size:        0.7 x 0.639788 x 0.639788 x ?
  Data strides:      [ 4 -1 -2 3 ]
  Format:            Internal pipe
  Data type:         unsigned 16 bit integer (little endian)
  Intensity scaling: offset = -500, multiplier = 0.2442
  Transform:               0.9997     0.00486     0.02455      0.2514
                        8.635e-10       0.981     -0.1942      -86.44
                         -0.02503      0.1941      0.9807      -133.9
  EchoTime:          0.002392
  FlipAngle:         5
  PixelBandwidth:    422
  RepetitionTime:    0.0068
  command_history:   mrconvert s1309_WIP_-_imag -  (version=3.0.3-52-gd7475aaa)
  comments:          7T049109 (20211014) [MR] WIP - imag
                     study: MR HJ�RNA [ ORIGINAL PRIMARY DERIVED_FFE DERIVED FFE ]
                     DOB: 14/10/2021
                     DOS: 14/10/2021 10:38:57
  dw_scheme:         0,0,0,0
  [257 entries]      0,0,0,0
                     ...
                     0,0,0,0
                     0,0,0,0
  mrtrix_version:    3.0.3-52-gd7475aaa

I have tried various mrconvert tricks but cannot get this into a 3D volume with correct dimensions and correct orientations. The faulty pixdim3=0.068 keeps dragging along.

Any advice?

Cheers,
Finn

2

Hey Finn,

Well that’s not one I’d come across before… I’m not sure what would cause this, but clearly the way these DICOM files are produced is a bit non-standard. I note this is a WIP sequence, it might be worth feeding this back to whoever produced this sequence.

As to what you can do about it: the most immediate problem can be fixed using the -axes option:

mrconvert s1309_WIP_-_imag -axes 3,1,2 out.nii.gz

But that will most likely still leave you with the wrong voxel size, since that option will carry the voxel size along with the axis (by the way, that value of 0.068 is most likely the TR, though I feels a bit long for that kind of sequence?). You’ll probably need to also overwrite the voxel size along the axis you’ve just moved, leaving the others as-is, which you can do with the -vox option:

mrconvert s1309_WIP_-_imag -axes 3,1,2 -vox 0.7,, out.nii.gz

(note the two commas after the 0.7,, for the -vox option: you’re providing empty values here, instructing mrconvert to leave the existing values unchanged).

That should get you 99% of the way there. There’s still a remaining possibility of getting the wrong origin for your transform matrix, but I have a feeling it’ll probably be correct – it depends on which slice is taken as the ‘anchor’ for the dataset, and I think in both cases (corrupted and corrected), it’ll be the same one. Double-check by overlaying with any other dataset from the same study if you have one… :crossed_fingers:

Good luck!
Donald