Dear Experts,

Hi, I have been using dcm2niix to convert DMRI files to BIDS format, and noticed a significant change in bvec file.

Using Siemens scanner, we have used customized diffusion vector file that looks like
CoordinateSystem = prs
vector[0] =( 0.0804, -0.3699, 0.9256) ...
Thus, I expected that the bvec output from dcm2niix will be somehow similar to this value (a little difference perhaps due to oblique acquisition).

But the result is something like
(-0.3699, 0.0804, 0.9256)
... showing that the x and y coordinates are switched.

Here I would like to ask you three things:
1. So what is the correct (meaning that it reflects what the scanner actually did) bvec file to use?
2. Do I have to switch x and y manually after obtaining bvec from dcm2niix, or should I change diffusion vector coordinate system to xyz, instead of prs?
3. Why is this happening?

Thank you very much for your help in advance!

Details regarding the how dcm2niix handles diffusion vectors is described here. The wiki includes sample datasets from each vendor, and links to a dedicated document that  describes how you can validate the generated vectors. 

I should note that all the gradient tables I have seen are specified as "CoordinateSystem = xyz" (with respect to scanner bore), rather than using phase, readout and slice directions (and in my experience, this is the frame of reference used to report the gradient directions in the DICOMs). Therefore, I would suggest carefully following the dedicated document to confirm the solution and generating an issue on the dcm2niix GitHub page if there are issues. I suspect all is well and the difference is in the direction of your prs phase-readout-slice coordinates to the ijk column-row-slice coordinates expected by FSL. As ever, recall that DICOM coordinates and NIfTI coordinates differ.  Therefore, dcm2niix expects Siemens to report vectors with respect to the scanner bore, and it must generate vectors in FSL format that is with respect to the image slices. 

The image orientation and vector direction expected by FSL are unusual, as described here and here. But dcm2niix's siemensPhilipsCorrectBvecs() function has provided robust FSL results with the validation datasets I acquired (provided on the dcm2niix wiki).

Dear Dr. Rorden,

Thank you very much for your detailed response. I read the attached documents and threads, and figured the problem out.
So I would say dcm2nii will expect xyz convention, probably because phase encoding directions can alter, while xyz is fixed.

I have checked the differences in DICOM and NIFTI convention, and it seems that it can happen in a way it changes x direction from positive to negative, or vice versa. The other diffusion MR data collected with Philips scanner was checked, and dcm2nii worked with no issues.

Just for future references I added a figure attached so what confusion happened regarding PRS and XYZ coordinate in our case.

Thank you again for your help.

Does dcm2niix generate the correct solution for converting gradients specified in PRS convention to FSL format? I would expect that Siemens reports the directions in the DICOM as scanner based XYZ, regardless of how they are specified in the sequence. Therefore, my assumption is that dcm2niix should convert your images correctly. If this is not the case, please generate an issue on the dcm2niix GitHub page. 

By the way, I would expect the conversion of PRS to XYZ will not always match your illustration. I would expect choosing Axial, Coronal or Sagittal slice geometry, as well as phase encoding dimension and polarity will impact this transformation.

For the first part of the question, I think the answer is yes.

If you refer to the illustration, P R S corresponds to (ant-pos, left-right, up-down) in my protocol.
Thus vector[0] =( 0.0804, -0.3699, 0.9256) ... was actually giving the scanner the values in "ant-pos, left-right, up-down" direction.
This case, the actual gradient will be y = 0.0804, x = -0.3699, z = 0.9256 in terms of scanner, and dcm2nii is actually giving these numbers in x y z directions.
It will be good if dcm2niix can read coordinate system information from DICOM file and indicate whether the gradient was in PRS or XYZ. However, .json file does not provide this detail to begin with, and I assume Siemens is not outputting that information. I assume it's a Siemens issue then.

What I will do, is I will try collecting Diffusion data using both PRS and XYZ coordinate system and see what dcm2nii creates. If there's still an issue I will reply to this again and post it to github.

For the second part of the question, yes, you are definitely correct. This is just an illustration in our case. XYZ as well as PRS can be different depending on setups of the scanner/readout directions.

Thank you again,

Dear Dr. Rorden,

I have an update from yesterday's questions and comments - so I have tested the DMRI acquisition using xyz coordinate system instead of prs, and it does solve orientation problem. Both older (2016) and newer (2019) dcm2niix gave the bvec file containing values in the order we want.
However, there is another issue that newly appeared: the sign of z direction is flipped.

When vector[0] =( 0.0804, -0.3699, 0.9256) is given, we get
x = 0.0804, y = -0.3699, z = -0.9256.
It was single B0 diffusion MR acquisition with 128 diffusion vectors, with phase encoding of posterior-anterior in Siemens Prisma.

I wonder if it's a known issue, or if I should post this as an issue in GitHub.
Thank you very much,


Originally posted by eegee:

Please generate a dcm2niix Github issue if the images fail to generate valid vectors with FSL, as described in the dedicated document I mentioned earlier. The frame of reference and slice order as saved to disk must be considered. The job of dcm2niix is to convert vectors from those stored in the Siemens DICOM image to FSL format.