Question regarding Philips bvecs correction

[dagra]

Hi,

while I was trying to debug some issues regarding a DTI from Philips, I noticed the function siemensPhilipsCorrectBvecs. As far as I can tell, this correction/tranformation is based on the orientation, which is the rotation, and it doesn't take into consideration the zooms/scales/PixelSpacings. As it's mentioned in the comment, the intention is to convert DTI vectors from scanner coordinates to image frame of reference where the scanner coordinates are in mm, but the image frame of reference may not be isotropic (i.e. the same voxel size in all dimensions). So my question is regarding the zooms: are they taken into account in the function and I can't find it? are they taken into account somewhere else? or they shouldn't be taken into account at all?

[neurolabusc]

When converting DICOM DWI files to NIfTI, dcm2niix generates a fsl format .bvec and .bval file. The fsl format stores b-vectors as unit vectors (e.g. they all have length of 1), with the magnitude provided in the b-value file. Therefore, the image scaling in mm is irrelevant: the important thing is the gradient direction (b-vec) and diffusion gradient strength (b-val). The critical thing is that Siemens and Philips report diffusion gradient direction in DICOM spatial coordinates. In contrast, the fsl coordinates are with respect to the image's frame of reference. Be aware that fsl internally will flip the first dimension of an image if it has a positive determinant (therefore, internally FSL images always have a negative determinant. The bevy files must be aware of this. A nice description of this is here.

I keep a validation repository of Philips DWI images with raw DICOMs and resulting bvec/bval files. I provide instructions for validating results here (download the "dedicated document"). I tend to find C code rather terse. For understanding these transforms, you may want to examine the lovely dicm2nii Matlab conversion. Since matrices are the foundation of Matlab, the matrix transformations are much more elegant in Matlab than C. Furthermore, from my perspective @xiangruili has a nice coding style and variable naming which is easy to read when considering the complexity of the proprietary file formats we must contend with.

[dimrozakis]

Hi @neurolabusc

First off, I'd like to thank you for the immediate response and the overall responsiveness, quality of your work and contribution to the open source community over the past years.

I work with @dagra and we've been brainstorming on this for the last couple of days. I feel we may be missing something and fear we may be somewhat misunderstanding something, so I'll try to ask a couple of questions which I hope will pinpoint the issue.

Question 1: Let's assume we have two different acquisitions, from the same scanner, using the same bvecs. Both of them have no rotation with regards to the scanner's frame of reference (world coordinates). One of these acquisitions, let's call it A, has a voxel size of 1x1x1. The second one, acquisition B, has a voxel size of 1x1x2. After converting the DICOM files of cases A & B to NIFTI (& bvec & bval files) using dcm2niix, should the bvec files be the same? It's my understanding that if the answer is yes, then indeed dcm2niix shouldn't take zooms into account but the statement "the fsl coordinates are with respect to the image's frame of reference" is misleading. If the answer is no, then the statement regarding fsl coordinates is correct, but then dcm2niix should take zooms into account.

A different way to pose the same question would be question 2: Suppose I have a DTI sequence with a given voxel size, say 1x1x2. I convert the DICOMs to NIFTI (& bvec & bval files) using dcm2niix. Before processing (tensor fitting etc) I wish to resample the sequence to voxels with size 1x1x1. Should I also modify the bvecs so that they match the new coordinate system?

Thanks in advance

[drmclem]

Hi - two quick comments which may help.

Firstly - as far as I am aware the scanner always outputs isotropic voxels on the inplane direction but the slice thickness can be different.

Any way - the vector table on the scanner is defined as a series of orientation vectors combined with a b value magnitude and the DICOM standard separates them the same way - so magnitude should be independant of direction.

(fffe,e000) na (Item with undefined length #=4) # u/l, 1 Item (0020,9164) UI [1.3.46.670589.11.71.5.0.7560.2014031011502405000] # 48, 1 DimensionOrganizationUID (0020,9165) AT (0018,9087) # 4, 1 DimensionIndexPointer (0020,9167) AT (0018,9117) # 4, 1 FunctionalGroupPointer (0020,9421) LO [Diffusion b-Value] # 18, 1 DimensionDescriptionLabel (fffe,e00d) na (ItemDelimitationItem) # 0, 0 ItemDelimitationItem (fffe,e000) na (Item with undefined length #=4) # u/l, 1 Item (0020,9164) UI [1.3.46.670589.11.71.5.0.7560.2014031011502405000] # 48, 1 DimensionOrganizationUID (0020,9165) AT (0018,9089) # 4, 1 DimensionIndexPointer (0020,9167) AT (0018,9117) # 4, 1 FunctionalGroupPointer (0020,9421) LO [Diffusion Gradient Orientation] # 30, 1 DimensionDescriptionLabel So the oreintation vectors are unit cosines in one orientation (typically patient) and if you want to work in a different orientation scheme you only need to modify the unit vectors - it is independant of FOV etc.

Another way to think about it - it doesn't matter if you have 1 or two slices, the direction and magnitude of the diffusion weighting B factor is the same.

[xiangruili]

bvec (direction) and bval (strength) are for each volume of data. When they are applied during acquisition, they are irrelevant to in-plane resolution or slice thickness.

[neurolabusc]

As @drmclem and @xiangruili have mentioned:

Question 1: These two images will have identical bvec/bval files Question 2: interpolating the image does not change the bvec/bval files.

In my own words, Siemens and Philips describe gradient vectors from the scanner's frame of reference (XYZ), you could think of this as left/right (X), anterior/posterior (Y) and superior/inferior (Z). The FSL format describes the vector in the image's frame of reference (IJK): columns (I), rows (J), and slices (K). Assuming the image is acquired orthogonal to the scanner bore the transform to IJK will be a matter of flipping the polarity of the vectors and swizzling the order of XYZ to IJK (which will vary for axial, coronal and sagittal acquisitions). If the scan is acquired oblique to the scanner bore, one will need to rotate the vectors. The fsl bvec IJK vector is a unit vector and only codes the applied gradient direction with respect to the image plane. The slice resolution and spacing between slices has no impact.

I assume your interest is spurred by recent studies (e.g. here and here) that suggest that interpolating data to higher resolutions can improve tractography. These findings come from well regarded groups, and they have provided some compelling data. Despite this promise, I personally would proceed with extreme caution. This is outside my field of expertise, but I would treat this as an experimental approach until it gets validated in a well-defined pipeline. First of all, an ex-vivo monkey brain is unlikely to show all the artifacts associated with acquiring a larger human brain, complicated by susceptibility, motion and pulsation artifacts. Second, higher order since interpolation does generate ringing artifacts. Third, one needs to be careful when the interpolation is conducted in a pipeline, as it interferes with some corrections.

As an aside, note that the NRRD (which dcm2niix creates with the -e y argument) adjusts the length to the bvec to encode the relative b-value. Again, spatial size does not impact the b-vectors, but slices acquired with a b-value less than the sequence maximum will have a length less than 1.

[dagra]

@drmclem @xiangruili @neurolabusc thank you very much for the thorough answers! They were very helpful!