Dw_scheme - dicom import or -fslgrad & -json_import

Should the dw_scheme and pe_scheme be the same in the 2 situations described below?

  1. dicom import version:
    mrcat dicom_ap/ dicom_pa all_dwis_dicom.mif -axis 3

  2. ap and pa files already converted to .nii.gz independently using dcm2niix version:
    mrconvert ap.nii ap.mif -fslgrad ap.bvec ap.bval -json_import ap.json -datatype float32
    mrconvert pa.nii pa.mif -fslgrad pa.bvec pa.bval -json_import pa.json -datatype float32
    mrcat ap.mif pa.mif all_dwis_imports.mif -axis 3

The ap an pa data are exactly the same shells/b-values with opposite phase encoding. I plan to use option 3 of dwipreproc*

Using mrinfo -dwgrad to compare all_dwis_dicom.mif with all_dwis_imports.mif the dw_schemes are different while the pe_schemes are the same.

*deprecated command with version 3.0.0 in favour of dwifslpreproc

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?

Below are some examples of gradients that should be the same:
-0.671761 -0.482801 0.561818 5 - from all_dwis_dicom.mif
-0.599209 0.57211 0.560035 5 - from all_dwis_imports.mif

0.999992 -0 0.00400391 1000 - from all_dwis_dicom.mif
0.976843 -0.205486 0.0596155 1000 - from all_dwis_imports.mif

0.591544 0.766766 -0.249289 2495 - from all_dwis_dicom.mif
0.441814 -0.853622 -0.275917 2495 - from all_dwis_imports.mif

Also the complete output from the 2 versions can be downloaded here.

Do these differences seem like more than precision differences?

Hi,

I believe this is relevant for this topic. I just found that when I convert the DICOM to .nii or .mif using dcm2nii (or dcm2niix) or mrconvert, the resulting bvecs are flipped in the x and the y axes.

The command lines used are the following:

dcm2nii DICOM/

and

mrconvert DICOM/ dwi.mif -export_grad_fsl mrconvert.bvecs mrconvert.bvals

I don’t know if this is a known issue, or the commands I’m using are not correct.

Best regards,

Manuel

Hi,

Just a quick update, when I use the option-export_grad_mrtrix the results are as expected, the only difference is the flipping in the x axes.

Regards,

Manuel

Definitely. At the very least, the y component is inverted - that’s not precision…

Can you check which version is correct? If you perform a quick tensor fit:

dwi2tensor dicom_ap/ - | tensor2metric - -vec dec_dicom.mif
dwi2tensor all_dwis_imports.mif - | tensor2metric - -vec dec_nii.mif

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.

Hi @jdtournier,

Thanks for your quick reply, here is the output of mrinfo for one of the dicom

mrinfo: [done] scanning DICOM folder "dcm_old/"
mrinfo: [100%] reading DICOM series "ep2d-advdiff-511E-head-FREE-20-P2"
mrinfo: [WARNING] Number of entries in mosaic slice timing (83) does not match number of images in mosaic (50); omitting
************************************************
Image:               "7099 (d6c25d30-fb8f-4aaa-ab61-a5d697a6572f) [MR] ep2d-advdiff-511E-head-FREE-20-P2"
************************************************
  Dimensions:        128 x 128 x 50 x 75
  Voxel size:        2 x 2 x 2 x ?
  Data strides:      [ -1 -2 3 4 ]
  Format:            DICOM
  Data type:         unsigned 16 bit integer (little endian)
  Intensity scaling: offset = 0, multiplier = 1
  Transform:                    1   2.051e-10           0      -122.8
                       -2.051e-10           1          -0      -150.2
                               -0          -0           1       -75.3
  EchoTime:          0.106
  FlipAngle:         180
  PhaseEncodingDirection: i-
  RepetitionTime:    7.3
  TotalReadoutTime:  0.046
  comments:          7099 (d6c25d30-fb8f-4aaa-ab61-a5d697a6572f) [MR] ep2d-advdiff-511E-head-FREE-20-P2
                     study: E131303 [ ORIGINAL PRIMARY DIFFUSION NONE ND NORM MOSAIC ]
                     DOB: ANON
                     DOS: 15/06/2015 12:32:31
  dw_scheme:         0.57735026,-0.57735038000000005,0.57735031999999997,5
  [75 entries]       0.57735026,-0.57735038000000005,0.57735031999999997,5
                     ...
                     -0.75905465999999999,-0.36947036,0.53602958000000001,750
                     -0.84493404999999999,0.29682966999999999,0.44494769000000001,750 

I can see in the data strides the -2.

I did the analysis with dtifit, and both images look fine, the tensors are correctly fitted, the only difference is the orientation and the image.

Regards,

Manuel

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.

Hi,

Thanks @jdtournier! Everything was as you described.

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.

Best regards,

Manuel

I am using version=3.0_RC3-51-g52a2540d but have no problem updating.

I think dec_dicom.mif i.e., from the dicom import version looks better, more coherent orientations but it was not so simple to differentiate between the 2.

Note (and apologies for) the change in language from ap/pa to lr/rl.

dicom import acq-lr:

mrinfo: [done] scanning DICOM folder "/Volumes/d...96000/DWI_MB3_DIR64_LR_0009"
mrinfo: [100%] reading DICOM series "DWI_MB3_dir64_LR"
************************************************
Image:               "OV2018RN1_A24 (83503) [MR] DWI_MB3_dir64_LR"
************************************************
  Dimensions:        124 x 124 x 48 x 137
  Voxel size:        1.54839 x 1.54839 x 1.55 x ?
  Data strides:      [ -1 -2 3 4 ]
  Format:            DICOM
  Data type:         unsigned 16 bit integer (little endian)
  Intensity scaling: offset = 0, multiplier = 1
  Transform:               0.9771      0.2006    -0.07057      -112.5
                          -0.2052      0.9765     -0.0662      -75.38
                          0.05563     0.07917      0.9953       -55.3
  EchoTime:          0.1
  FlipAngle:         90
  MultibandAccelerationFactor: 3
  PhaseEncodingDirection: i
  RepetitionTime:    5
  SliceEncodingDirection: k
  SliceTiming:       0,2.19749999,4.39249992,1.57000005,3.7650001,0.942499995,3.13750005,0.314999998,2.50999999,4.70749998,1.88250005,4.07999992,1.255,3.4525001,0.627499998,2.82500005,0,2.19749999,4.39249992,1.57000005,3.7650001,0.942499995,3.13750005,0.314999998,2.50999999,4.70749998,1.88250005,4.07999992,1.255,3.4525001,0.627499998,2.82500005,0,2.19749999,4.39249992,1.57000005,3.7650001,0.942499995,3.13750005,0.314999998,2.50999999,4.70749998,1.88250005,4.07999992,1.255,3.4525001,0.627499998,2.82500005
  TotalReadoutTime:  0.0588
  comments:          OV2018RN1_A24 (83503) [MR] DWI_MB3_dir64_LR
                     study: CRANE BREBIS [ ORIGINAL PRIMARY DIFFUSION NONE MB ND MOSAIC ]
                     DOB: 15/03/1978
                     DOS: 27/03/2018 14:18:24
  dw_scheme:         0.57735020000000004,0.37435877000000001,0.72561854000000003,5
  [137 entries]      0.57735020000000004,0.37435877000000001,0.72561854000000003,5
                     ...
                     0.72152042000000005,-0.60892170999999995,-0.32958007,2495
                     0.26654378000000001,-0.95980692000000001,0.087893929999999995,2500

dicom import acq-rl:

mrinfo: [done] scanning DICOM folder "/Volumes/d...96000/DWI_MB3_DIR64_RL_0003"
mrinfo: [100%] reading DICOM series "DWI_MB3_dir64_RL"
************************************************
Image:               "OV2018RN1_A24 (83503) [MR] DWI_MB3_dir64_RL"
************************************************
  Dimensions:        124 x 124 x 48 x 137
  Voxel size:        1.54839 x 1.54839 x 1.55 x ?
  Data strides:      [ -1 -2 3 4 ]
  Format:            DICOM
  Data type:         unsigned 16 bit integer (little endian)
  Intensity scaling: offset = 0, multiplier = 1
  Transform:               0.9771      0.2006    -0.07057      -112.5
                          -0.2052      0.9765     -0.0662      -75.38
                          0.05563     0.07917      0.9953       -55.3
  EchoTime:          0.1
  FlipAngle:         90
  MultibandAccelerationFactor: 3
  PhaseEncodingDirection: i-
  RepetitionTime:    5
  SliceEncodingDirection: k
  SliceTiming:       0,2.19749999,4.39249992,1.57000005,3.7650001,0.942499995,3.13750005,0.314999998,2.50999999,4.70749998,1.88250005,4.07999992,1.255,3.4525001,0.627499998,2.82500005,0,2.19749999,4.39249992,1.57000005,3.7650001,0.942499995,3.13750005,0.314999998,2.50999999,4.70749998,1.88250005,4.07999992,1.255,3.4525001,0.627499998,2.82500005,0,2.19749999,4.39249992,1.57000005,3.7650001,0.942499995,3.13750005,0.314999998,2.50999999,4.70749998,1.88250005,4.07999992,1.255,3.4525001,0.627499998,2.82500005
  TotalReadoutTime:  0.0588
  comments:          OV2018RN1_A24 (83503) [MR] DWI_MB3_dir64_RL
                     study: CRANE BREBIS [ ORIGINAL PRIMARY DIFFUSION NONE MB ND MOSAIC ]
                     DOB: 15/03/1978
                     DOS: 27/03/2018 14:07:15
  dw_scheme:         -0.67176115999999997,-0.48280126000000001,0.56181835999999996,5
  [137 entries]      -0.67176115999999997,-0.48280126000000001,0.56181835999999996,5
                     ...
                     0.72152042000000005,-0.60892170999999995,-0.32958007,2495
                     0.26654378000000001,-0.95980692000000001,0.087893929999999995,2500

nifty import acq-lr:

************************************************
Image:               "nifti/test-sub24-ses1-imports/sub-24_ses-1_acq-lr_dwi.mif"
************************************************
  Dimensions:        124 x 124 x 48 x 137
  Voxel size:        1.54839 x 1.54839 x 1.55 x 5
  Data strides:      [ -1 2 3 4 ]
  Format:            MRtrix
  Data type:         signed 16 bit integer (little endian)
  Intensity scaling: offset = 0, multiplier = 1
  Transform:               0.9771      0.2006    -0.07057      -112.5
                          -0.2052      0.9765     -0.0662      -75.38
                          0.05563     0.07917      0.9953       -55.3
  AccelFactPE:       2
  AcquisitionNumber: 1
  AcquisitionTime:   14:17:59.620000
  BandwidthPerPixelPhaseEncode: 16.9780006
  ConversionSoftware: dcm2niix
  ConversionSoftwareVersion: v1.0.20170724 (OpenJPEG build) GCC6.1.0
  DeviceSerialNumber: 40849
  EchoTime:          0.100000001
  EffectiveEchoSpacing: 0.000474998
  FlipAngle:         90
  ImageType:         "ORIGINAL"
  [7 entries]        "PRIMARY"
                     ...
                     "ND"
                     "MOSAIC"
  MagneticFieldStrength: 3
  Manufacturer:      Siemens
  ManufacturersModelName: Verio
  PhaseEncodingDirection: i
  PhaseEncodingLines: 124
  ProcedureStepDescription: CRANE_BREBIS
  ProtocolName:      DWI_MB3_dir64_LR
  RepetitionTime:    5
  ScanningSequence:  EP
  SequenceName:      ep_b5
  SequenceVariant:   SK_SS
  SeriesDescription: DWI_MB3_dir64_LR
  SliceTiming:       0
  [48 entries]       2.1975
                     ...
                     0.6275
                     2.825
  SoftwareVersions:  syngo_MR_B19
  TotalReadoutTime:  0.0427497998
  TrueEchoSpacing:   0.000949996
  command_history:   mrconvert "nifti/sub-24/ses-1/dwi/sub-24_ses-1_acq-lr_dwi.nii.gz" "sub-24_ses-1_acq-lr_dwi.mif" "-fslgrad" "nifti/sub-24/ses-1/dwi/sub-24_ses-1_acq-lr_dwi.bvec" "nifti/sub-24/ses-1/dwi/sub-24_ses-1_acq-lr_dwi.bval" "-json_import" "nifti/sub-24/ses-1/dwi/sub-24_ses-1_acq-lr_dwi.json"  (version=3.0_RC3-51-g52a2540d)
  comments:          TE=1e+02;Time=141759.620;phase=0;dwell=0.475
  dw_scheme:         0.4378534227,-0.5320743376,0.7246943466,5
  [137 entries]      0.4378534227,-0.5320743376,0.7246943466,5
                     ...
                     0.8504148748,0.4683430872,-0.2396860077,2495
                     0.4467611464,0.8767068001,0.178298019,2500
  mrtrix_version:    3.0_RC3-51-g52a2540d

nifty import ace-rl

************************************************
Image:               "nifti/test-sub24-ses1-imports/sub-24_ses-1_acq-rl_dwi.mif"
************************************************
  Dimensions:        124 x 124 x 48 x 137
  Voxel size:        1.54839 x 1.54839 x 1.55 x 5
  Data strides:      [ -1 2 3 4 ]
  Format:            MRtrix
  Data type:         signed 16 bit integer (little endian)
  Intensity scaling: offset = 0, multiplier = 1
  Transform:               0.9771      0.2006    -0.07057      -112.5
                          -0.2052      0.9765     -0.0662      -75.38
                          0.05563     0.07917      0.9953       -55.3
  AccelFactPE:       2
  AcquisitionNumber: 1
  AcquisitionTime:   14:05:16.615000
  BandwidthPerPixelPhaseEncode: 16.9780006
  ConversionSoftware: dcm2niix
  ConversionSoftwareVersion: v1.0.20170724 (OpenJPEG build) GCC6.1.0
  DeviceSerialNumber: 40849
  EchoTime:          0.100000001
  EffectiveEchoSpacing: 0.000474998
  FlipAngle:         90
  ImageType:         "ORIGINAL"
  [7 entries]        "PRIMARY"
                     ...
                     "ND"
                     "MOSAIC"
  MagneticFieldStrength: 3
  Manufacturer:      Siemens
  ManufacturersModelName: Verio
  PhaseEncodingDirection: i-
  PhaseEncodingLines: 124
  ProcedureStepDescription: CRANE_BREBIS
  ProtocolName:      DWI_MB3_dir64_RL
  RepetitionTime:    5
  ScanningSequence:  EP
  SequenceName:      ep_b5
  SequenceVariant:   SK_SS
  SeriesDescription: DWI_MB3_dir64_RL
  SliceTiming:       0
  [48 entries]       2.1975
                     ...
                     0.6275
                     2.825
  SoftwareVersions:  syngo_MR_B19
  TotalReadoutTime:  0.0427497998
  TrueEchoSpacing:   0.000949996
  command_history:   mrconvert "nifti/sub-24/ses-1/dwi/sub-24_ses-1_acq-rl_dwi.nii.gz" "sub-24_ses-1_acq-rl_dwi.mif" "-fslgrad" "nifti/sub-24/ses-1/dwi/sub-24_ses-1_acq-rl_dwi.bvec" "nifti/sub-24/ses-1/dwi/sub-24_ses-1_acq-rl_dwi.bval" "-json_import" "nifti/sub-24/ses-1/dwi/sub-24_ses-1_acq-rl_dwi.json"  (version=3.0_RC3-51-g52a2540d)
  comments:          TE=1e+02;Time=140516.615;phase=1;dwell=0.475
  dw_scheme:         -0.5992085561,0.5721095199,0.5600347448,5
  [137 entries]      -0.5992085561,0.5721095199,0.5600347448,5
                     ...
                     0.8504148748,0.4683430872,-0.2396860077,2495
                     0.4467611464,0.8767068001,0.178298019,2500
  mrtrix_version:    3.0_RC3-51-g52a2540d

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:

I am not 100% sure of the answer to this question! I can test any other suggestions you have to try and be sure and/or share a data set with you if you think it would help?

Yes, I’d figured from ‘CRANE BREBIS’ in your previous mrinfo output… :wink:

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_dicom-rl.mif (RL only, 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).

Thanks,
Donald.

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?

Yes it is.

I agree.

Here you go - note the L/R (really I/S) flip in the FA data.

I confirm :grinning:

  1. dcm2niix (v1.0.20170724 (OpenJPEG build) GCC6.1.0)
  2. dtifit
  3. FSL eyes to look at the V1 overlaid on the FA

I also added the FA (sub-24_ses-1_acq-rl_dwi-dtifit_FA) and V1(sub-24_ses-1_acq-rl_dwi-dtifit_V1) from this pipeline here.

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.

Makes sense.

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:

1 0 0 0 
0 0 -1 0
0 1 0 0
0 0 0 1

Then apply that transform matrix to the data:

mrtransform all_dwis_dicom.mif -linear transform.txt all_dwis_dicom_reoriented.mif

This should also take care of reorienting the DW gradients along with the images (pretty important – please check afterwards using the same approach as above).

OK, that’s good to hear (at least for us). I’ll give Chris Rorden a nudge about this issue now.

Thanks for sticking with it! :+1:
Cheers,
Donald.

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.

  1. Spatial coordinates: Does the DICOM header list this data as from BIPED or QUADRUPED?
  2. Do you have a validation dataset as linked in the dedicated document?

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,
 929      with
 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…

What do you reckon?