These should be the same, but there will likely be subtle differences, introduced by precision issues due to the various conversions that will happen along the way. How different are the schemes, exactly?
which one of these provides the right orientations when displayed in mrview using the fixel plot tool?
Also: which version of MRtrix3 are you running? Anything older than version 0.3.14 (released 2½ years ago) will be affected by this bug.
To get to the bottom of this, can you post the output of mrinfo dicom_ap/ dicom_pa/ ap.nii pa.nii? Note that you may need to edit the output to remove patient-identifiable information.
One more thing if you find the time: are you 100% sure that the original NIfTI images were converted correctly? If you run FSL’s dtifit on your ap.nii image (using a recent version of FSL), do you obtain vectors that match the expected anatomy?
Thanks @mblesac – although this is probably not a bug, depending on whether the NIfTI images produced were regridded in any way during the dcm2nii call. The DICOM standard coordinate system is right-handed, and preserved by a direct mrconvert call. FSL however internally assumes a left-handed coordinate system, and this has historically led to problems with RAS images (RAS is a right-handed coordinate system, and the default NIfTI coordinate system – sometimes naively referred to as ‘neurological’). Recent versions of FSL should handle them fine nowadays, but a lot of converters will nonetheless produce LAS images to avoid issues of this type. We only found out relatively recently that the bvecs should be interpreted differently depending on the handedness of the coordinate system (this is what the bug I mentioned above was all about – follow the link for details). To really get to the bottom of whether this is a bug or not, I’d need to see the output of mrinfo on all the relevant images (particularly the strides and transform entries). Or you could verify yourself whether there is an inconsistency by running dtifit and displaying the vectors overlaid on the corresponding data, and check whether they are consistent with anatomy…
Coming back to the original report: this could be relevant here, but only if @scott’s installation is older than version 0.3.14. If it’s up to date, this would be a serious concern… The best thing to do at this stage would be to send me the data so that I can take a closer look.
Good to hear. Your DICOM look like regular straight axial images, which is reflected in the identity transform (at least the rotation 3x3 part), and reversed strides for the x & y axes (that’s the DICOM standard frame).
I expect if you ran mrinfo on your NIfTI images, you’ll most likely find the same strides for the MRtrix3 converted one, and strides [ -1 2 3 4 ] for the dcm2nii converted image (which corresponds to LAS, as historically expected by FSL). The MRtrix3 converted image would likely display back to front in fslview, but the computed vectors should match the anatomy when overlaid on their respective original images – which if I understand correctly is what you’ve observed. So all is as it should be!
Incidentally, if you want to perform the equivalent conversion to dcm2nii using mrconvert, it should be sufficient to add the -stride -1,2,3,4 option to the call. If you do that, the bvecs should then match exactly.
Goes to show how tricky it can be to handle this information… This is very much why we strongly recommend to users to use the mif format whenever possible: the bvecs/bvals are then baked into the image header, and MRtrix3 then takes care of ensuring it remains consistent with the data. See this page for details.
Another question related with the strides, I have a dwi.mif image with strides [ -1 2 3 4 ], it was converted using dcm2nii. When I create the FOD the strides of the FOD image change completely [ -2 3 4 1 ], however they look perfectly aligned. What’s the reason of this? For memory optimization? Thanks in advance.
I did the dtifit (FSL version 5.0.11) as suggested and (I think) the results are similar to the dec_nii.mif version. I am a little reluctant to say the vectors are wrong because it is not so easy for me to tell but I have a few indices that indicate that the dicom imported vectors make more sense. The bvecs for the fsl version were output by simple dcm2niix -z y -f dicom-dir -o out.nii.gz call.
Essentially, yes. The output of commands like dwi2fod and dwi2tensor is by default volume-contiguous (stride 1 along the 4th dimension), since these data are typically processed voxel-wise in downstream applications (e.g. during tractography). Having all the coefficients for each voxel co-located in RAM can significantly improve performance in these applications, by making more efficient use of the CPU cache and memory bandwidth.
Note that this is only possible for data formats that support volume-contiguous storage (only .mif and .mih currently). For other formats such as NIfTI, they’ll be stored as regular spatially-contiguous volumes.
No need, that’s up to date enough to rule out the issue I was worried about.
That’s a relief… If you’re not sure, you can always post a screenshot, we should be able to tell you straight away. Given the discrepancy in your bvecs, I expect you’ll see a clear difference in splenium of the corpus callosum, with the directions running at an odd angle in the corrupted case.
OK, I assume that would mean the original bvecs produced by dcm2niix are already incorrect…? We’d really need to be sure about that before proceeding any further, for obvious reasons. Again, a few screenshots would really help. If there really is an issue, I reckon Chris Rorden might like to hear about it…
First off this is data from sheep, not humans.
Second here you can download:
dec_nii.mif (vectors from the nifty import version from both rl and lr)
dec_dicom.mif (from the dicom version with both lr and rl concatenated)
dec_dicom-rl.mif (dicom but only rl)
fa-dicom-rl.mif (the FA image from dicom importing the rl sequence) which can be used for anatomy.
If you are willing to try and understand some sheep brain anatomy you could compare using these images rather than screenshots. Here is a screenshot that will help with general orientation of the images:
Yes, I’d figured from ‘CRANE BREBIS’ in your previous mrinfo output…
OK, looking at the images, there’s an issue with the orientation of the brain: MRtrix3 seems to think that AP IS, which is not what you’re showing in your (FSLView?) screenshot. I’m surprised to see such a discrepancy. Is that FA image you’re showing the same as what you sent me…?
Nevertheless, it’s clear there is a difference, which looks like an inversion of the y axis, as far as I can tell – which matches the bvecs discrepancy. Here’s the images, as a sagittal projection (although it looks rotated by 90°) – I’m looking at the location under the crosshairs, which I assume is corticospinal tract, at the level of the brainstem:
dec_dicom.mif (straight from DICOM): seems correct
dec_nii.mif (from dcm2niix, imported into MRtrix3): seems wrong (inversion of Y component of vectors). Note that the supposed directions of the fibres are no longer aligned with the presumed direction of the CST at that level.
So from these data, it’s clear MRtrix3’s direct DICOM import works as expected.
I still can’t rule out an issue within MRtrix3 with the bvecs import though, from the data you’ve sent me. For that, I’d need to confirm that the issue also exists when processing the data entirely outside of MRtrix3, using FSL’s dtifit and displaying within FSLView. Any chance you could load your dtifit results into FSLView, find a similar projection to what I’m showing here, and post a screenshot of that? And also confirm that these data have been produced without any involvement of MRtrix3 whatsoever? If the orientations in these data also seem incorrect, then I’ll feed that back to Chris Rorden straight away. I might ask you to check which version of dcm2niix you’re using though – and maybe verify that it’s relatively up to date (might be an old bug that’s since been fixed).
The screenshot was from an mrview display. We always have this orientation issue (discrepancy) with our sheep data and for monkey data too. I always thought it was just because the animal is in the scanner head first prone. I normally reorient T1 / T2 images to something more standard using, for example, c3d -orient LIP (see screenshot below). A side question: is changing the ‘strides’ the best (equivalent) option to this in mrtrix and are the orientations/layouts (ignore L&R - I have a vitamin E in the T1 to figure it out) in this screenshot those desired for mrtrix?
Ah, sorry – got confused with the manual orientation labels you’d presumably added on top. Looking closer, I can see that the original mrview ones are the same as what I see. All good.
No, changing the strides will not change the orientation of the data – only how the voxels are ordered on file. Your best bet here would be to use mrtransform -linear with a suitable 4x4 rotation matrix. Something like this might do the trick:
Create a file transform.txt with the following rigid-body rotation:
Hello, I apologize that I am busy with other things and do not have much time. The link above I saw was for the converted data - did you share the DICOMs? I have a couple thoughts off the top of my head.
I have never seen a quadruped dataset, but if you do acquire a validation dataset it would be great if you could share it. Due to its Analyze roots, FSL makes has some unusual expectations regarding bvecs and bvals.
Wow, I never knew about this… In any case, I’m not sure this matters, as long as everything is consistently provided within this coordinate system, right? MRtrix3 certainly doesn’t consider this at all, and everything comes out consistent, as far as I can tell…
I am not 100% sure. I have not seen one of these images, but dcm2niix will elicit the error Anatomical Orientation Type (0010,2210) is QUADRUPED: rotate coordinates accordingly" if it encounters such an image. I think the consequences depend on the vendor. For GE, the DICOM file stores images with respect to the image plane (specifically 0019,10bb, 0019,10bc and 0019,10bd refer to the Frequency, Phase, and Slice direction. Therefore, there should be no impact. However, I suspect this would require an orthogonal rotation such as the one suggested if the data is from Siemens, Philips or UIH.
Is that a fatal error or just a warning? If an error, then that would indicate this is not the issue here. Also, the anatomical labels shown in MRView are consistent with regular human head-first supine prone positioning, assuming the position of the sheep’s head means the equivalent of AP ends up along the scanner z-axis (and hence labelled IS in the screenshot).
OK, this is where the issue might be. I think it’s a matter of interpretation, particularly of what the NIfTI standard frame actually means. In DICOM, all coordinates are provided relative to the DICOM patient-centred coordinate system (PCS), which importantly is not fixed relative to the scanner axes. I would expect this biped/quadruped entry to affect the PCS, same as putting the patient in feet-first, etc. The idea is to ensure that the anatomical orientation labels (LR, AP, IS) retain their expected meaning relative to the patient independently of how they were positioned in the scanner.
The PCS is the frame that any position or vector information in the DICOM headers should be provided relative to – including the DW gradient orientations. I’m pretty confident this holds for Siemens, not sure about Philips (not seen any indication to the contrary yet, but I’m not sure I’ve come across non-HFS data yet). GE stored them relative to phase-read-slice, so that doesn’t apply. However, the dedicated tags in the new DICOM standard ((0018,9087) Diffusion b-value, and (0018,9089) Diffusion Gradient Orientation) also expect them to be provided relative to the PCS – at least, that’s what the standard suggests (could be clearer though: “The direction cosines of the diffusion gradient vector with respect to the patient”).
So for instance, I’ve been sent intra-operative dMRI data with the patient acquired in the ‘decubitus left’ position (on their side). Yet it all displayed in MRView in the expected orientation, as if they’d been scanned in the regular supine position: left still means the left side of the patient’s brain, etc. Interestingly, the DW gradients did not match in that case, but this was a Siemens bug (it also affected their own processing on the scanner console) – acknowledged by them at the time, should be fixed by now, that was ~7 years ago…
But the point is, you shouldn’t need to even worry about this at all if you’re interested in the coordinate system remaining anatomically-based. However, if you interpret the NIfTI frame as being fixed relative to scanner x,y,z, then you would need to worry about it. I scratched my head about this some years ago (when sent these ‘decubitus left’ data), and figured that the safest and least unexpected way to handle this was to stick with the DICOM PCS, and essentially implicitly assume the same convention within MRtrix3. In fact, I’ve just noticed that this is also consistent with the NIfTI standard (bit late, I know…). If you look at the nifti1.h file, you’ll find these lines in the comments:
927 The (x,y,z) coordinates refer to the CENTER of a voxel. In methods
928 2 and 3, the (x,y,z) axes refer to a subject-based coordinate system,
930 +x = Right +y = Anterior +z = Superior.
So from that point of view, I reckon the right course of action is simply to ignore whether the subject is biped or quadruped, or indeed which position they were put into the scanner, and leave all the handling of these details to the scanner’s DICOM implementation…