questions
questions > RE: Question about bvec (diffusion MR) converted using dcm2niix
Sep 20, 2019 04:09 PM | eegee
RE: Question about bvec (diffusion MR) converted using dcm2niix
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:
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:
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,
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,
Threaded View
| Title | Author | Date |
|---|---|---|
| eegee | Sep 19, 2019 | |
| Chris Rorden | Sep 19, 2019 | |
| eegee | Sep 19, 2019 | |
| eegee | Sep 20, 2019 | |
| Chris Rorden | Sep 20, 2019 | |
| Chris Rorden | Sep 19, 2019 | |
| eegee | Sep 19, 2019 | |