DWI bvec/bval and images volumes dimension problem

Hello,
I am newly working on diffusion MRI, but I have some question about the data dimension, here is the problem:
Yooo, mec, I run one PREVDEMALS subject for FREESURFER diffusion pipeline, so I found a interesting question and got some interesting result about the bvec/bval and dwi.nii dimension problems.

Basically, in my dataset, all the dwi imges(.dwi.nii.gz), they have 137 volumes/nFrames during the session, and the bvec/bval have 136 columns(nFrames-1), this works well for Nipype(Mrtrix and Dipy) pipelines, but when i run it in TRACULA, it complains the error that the data and the bvec/bval dont have the same entries, which makes sense, So I found information for Freesurfer, it is said that

'The bvalues are in a simple text file, one for each direction
(including b=0). The bvectors (gradient directions) are also in a
simple text file with three components on each row. These also include
the b=0 values. There must be as many rows in the bvals/bvecs
as there are frames in the input’

So to avoid the error, I just add 0 for the first column for bvec and bval, the pipeline run without errors, but when I check out the the outputs, I found that for the fractional anisotropy(fa.nii), it is not right, some high values bigger thatn 1, which is impossible, So I guess the problem is that its the adding 0s.

So my question is that, when define the bvec and bval, why the dimension is nFrames-1, but Freesurfer requires the same dimensions??

BTW, my data is in the BIDS specification.

Really need your help:)
Happy Christmas

Hao

Hi there, just came to this post. I had a bit experience working with DWI, and found when discussing a problem about DWI, it’s always good (or probably necessary) to describe clearly an image’s associated bval & bvec, or maybe even show them, so others can better help you.

From my personal experience, among all the DWI datasets, images actually come with a .bval and a bvec file of same dimension (nFrames), instead of nFrames - 1. And actually, if you look at the tensor fitting equation (a pseudo-inverse, or OLS), it requires same dimension of signal intensities and bmatrix (which is constructed from bval & bvec), so these three should have same dimensions. If they are not, there’s probably a problem in the dataset.

So I doubt that dipy, etc. can process even w/o any warning? I guess they might do some autofilling on bmatrix, but the result isn’t necessarily correct.

a DWI’s b = 0 volumes are not necessarily always in the first, they can also be interleaved in the volumes, that might be a reason after you adding 0s in the first column you see FA map that doesn’t make sense.

(just noticed it’s a 3-yr-old post… it might be of some value for others so I’ll just keep it here)

I am going to guess the data came fro a Philips scanner, where a derived Isotropic image was inserted into the raw data. For example, consider a simple scan with one B=0 volume and six direction B=1000 volumes. In this case, if the scanner console was set to generate an derived image, Philips will create a DICOM series with 8 volumes (1B=0, 6B=1000, 1*DERIVED). The isotropic image is essentially the average of the B=1000 scans, and must be removed for further processing. For Siemens users derived scans are always saved as a separate series, avoiding confusion. You could always use a tool like fslroi to remove the derived image.

If you use dcm2niix to convert a Philips DWI that inserts a derived scan into the series, it will generate two NIfTI images, e.g. 6.nii, 6_ADC.nii, 6.bvec, 6.bval. The file 6_ADC.nii includes the derived image(s), while 6.nii discards it. I would recommend using the ignore feature of dcm2niix -i y that will simply not generate the 6_ADC image in the first place. You will always be able to create a better isotropic image after you process you image (de-gibbs, denoise, Eddy, TOPUP).

1 Like