Hello,
I have a question about the output of mrinfo.
Why is the voxel size contain (?) using mrconvert? Why are the strides/transform different between dcm2nii and mrconvert (.nii)?
Will the voxel size (?) be a problem for later analysis?
This is the same file converted with 1) dcm2nii and 2) mrconvert (.mif) 3) mrconvert (.nii)
-
dcm2nii output (.nii)
Dimensions: 96 x 96 x 74 x 160
Voxel size: 1.08333 x 1.08333 x 1.08 x 11.23
Data strides: [ -1 2 3 4 ]
Format: NIfTI-1.1 (GZip compressed)
Data type: signed 16 bit integer (little endian)
Intensity scaling: offset = 0, multiplier = 1
Transform: 0.9952 0 -0.09758 -44.87
0 1 -0 38.92
0.09758 0 0.9952 -58.49
-
mrconvert (.mif)
Dimensions: 96 x 96 x 74 x 160
Voxel size: 1.08333 x 1.08333 x 1.08 x ?
Data strides: [ -1 -2 3 4 ]
Format: MRtrix
Data type: unsigned 16 bit integer (little endian)
Intensity scaling: offset = 0, multiplier = 1
Transform: 0.9952 0 -0.09758 -44.87
0 1 0 38.92
0.09758 -0 0.9952 -58.49
-
mrconvert (.nii)
Dimensions: 96 x 96 x 74 x 160
Voxel size: 1.08333 x 1.08333 x 1.08 x ?
Data strides: [ -1 -2 3 4 ]
Format: NIfTI-1.1
Data type: unsigned 16 bit integer (little endian)
Intensity scaling: offset = 0, multiplier = 1
Transform: 0.9952 0 -0.09758 -44.87
0 1 0 38.92
0.09758 -0 0.9952 -58.49
1 Like
The voxel size that gets labelled as ? corresponds to the 4th (volume) axis. I expect dcm2nii fills this with the repetition time, assuming it’s a time series (it’s not really a ‘voxel size’ anyway beyond the 3rd dimension…). In MRtrix3, we don’t make that assumption since the software is geared primarily at diffusion MRI, where the concept of an ‘interval’ between samples along the volume axis doesn’t really make sense: they typically correspond to different b-values / DW directions, so we would generally leave that undefined.
This will be due to the re-ordering of the voxels that dcm2nii will perform by default to ensure all output data are stored as LAS. Note that strictly speaking, the NIfTI convention is RAS, but in practice LAS is the safest convention to use to ensure compatibility with e.g. FSL (mostly for historical reasons, due to the legacy of the Analyze image format). Other converters may perform re-ordering differently, or not at all. None of them are wrong, these different images are all consistent with the original data, and with the NIfTI standard.
If you need mrconvert to generate data that match dcm2nii, you can add the -stride -1,2,3 option to your mrconvert call, and you should then get the same strides.
To get a full understanding of what’s going on here requires a deep dive into strides and transforms – not to be undertaken lightly… If you’re interested, I recommend you have a read of our documentation about image strides, and also this post for a more complete explanation.
3 Likes