Get bvec / bval in FSL format and mrtrix format

[manuegrx]

As explain here, mri_conv allows to obtain bvec and bval in one file in MRTRIX format (if the option is check, a bvecs/bvals text file with a '-bvecs-bvals-MRtrix' suffix and a '.txt' extension is created) for DICOM (Philips and Brucker).

If we used the option "save bvecs & bvals in 2 files", one file is created for bval and an other for the bvec. Following my request the extension of the file have been change to .bvec and .bval (see https://github.com/populse/mri_conv/commit/0e1ed5937bcfe7529db0c0a2b97df33f3f00e6a1) in order to be similar to FSL format. However in this case it is not in FSL format but is is still as in MRTRIX format because in FSL format the gradient vectors should be provided with respect to the image axes, not in real or scanner coordinates (as it is the case for MRTRIX format) !

We can find the differences between the two format here but the main features are the following:

• MRTRIX format : a single ASCII text file with one row per DWI volume (a row = x y z b where [ x y z ] are the components of the gradient vector, and b is the b-value in units of s/mm²) AND the direction vectors are assumed to be provided with respect to real or scanner coordinates (same convention as for DICOM)

• FSL format: a pair of ASCII text files (bval file = a one row with one b value per DWI volume; bvec file = 3 rows of space-separated floating-point values, with first row = x-component, second row = y-component, and third row = z-component). The gradient vectors are provided with respect to the image axes, not in real or scanner coordinates

If we import BIDS format in mri_conv, the bvec/bval imported are in FSL format.

It could be nice if mri_conv allows to have both MRTRIX format and FSL format when we import DICOM (and PARE_REC but I did not tested yet).

If it is not possible to get FSL format for now, maybe we could change a little be the documentation to make things clearer !

[manuegrx]

I need to do more test and to check with different data but it seems that currently in mri_conv the bvec are always provided with respect to the image axes, not in real or scanner coordinates (so like the FSL format)

[montigno]

Hi @manuegrx,

If you have an algorithm or code that allows to generate real bvec/bval FSL, I can integrate it into mri_conv. For the Dicom I based myself on this site http://neurohut.blogspot.com/2015/11/how-to-extract-bval-bvec-from-dicom.html. We see that in step 4, we transpose the vectors to the image reference plane. I don't remember with which software I compared the bvec/bval (Dicomifier or dcm2niix), but it was quite similar. We can work together to have good code for each MRI format (Bruker, Dicom, Philips, etc.).

[manuegrx]

Hi @montigno !

I'll be out of the office for 2 weeks but when I come back I'm available to work together on this subject !

I will first create a small database with data for each format/ each constructor and test with dcm2niix and mrtrix to know exactly what we need to have for each format (mrtrix and fsl)

[montigno]

very good idea !!

[manuegrx]

I began to gather some data and to compare mri_conv / dcm2niix and mrtrix. Here are some first comments:

• For Siemens data (tested on Classic DICOM from XA version and Classic DICOM from VE version), mri_conv does not export bvec and bval file. Bvec and bval are stored in different tags from those used for Philips data. It will be also the case for GE data (I do not have a sample to test).
  --> it will be necessary to add the correct tag for Siemens and GE in mri_conv --> if we want to implement for GE data we need to be careful as it is not the same logic as for Philips and Siemens (see here)

• For Philips DICOM data, bvec exported by mri_conv (for FSL format . bvec/ . bval and for mrtrix format) are the same as the one exported by dcm2niix (not exactly the same rounding) except for the y axis that seems flipped (same value but + instead of - and vice-versa). --> it confirms that the bvec exported currently by mri_conv are in FSL format. We need to understand whether the inverted y-axis is a problem and see if we need to change it. --> to get mrtrix format with mri_conv we need to save in the "bvecs-bvals-MRtrix.txt" the bvec before to transpose the vectors to the image reference plane

• For Philips PAR REC data, bvec extrated by mri_conv are not the same as the one extracted by dcm2niix (value are a little bit different and x-axis is flipped). I think that the bvec given by mriconv are not in the image reference plan (the bvec exported are the one written in the PAR file without modification) --> we need to confirm that the bvec in the PAR file are given in the scanner plan and not in the image reference plan. If it is the case we need to transpose the vectors to the image reference plane to get the bvec in FSL format (and keep the bvec in the scanner plan for mrtrix format).

@montigno I am available to discuss about this

[manuegrx]

As discussed with @montigno yesterday the priority is to change the code for Philips (DICOM and PAR/REC) and brucker data in order to have both fsl format and mrtrix format. The main modifications to do are:

• for Philips DICOM, save the "bvecs-bvals-MRtrix.txt" before to do the reorientation in image space
• for Philips PAR/REC and brucker data, add the reorientation in image space to get FSL format

In a second time, it will be great to add correct tag for Siemens and GE. It is a little be more complicated as it will be necessary to change the way to get the tag depending on the manufacturer/ type of DICOM. For GE it will be necessary to add a "correction" to have the bvec in FSL format.

Here is a quick table with the different tags used for bvec/ bval (filled with dcm2niix info and with test data) :

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

Manufacturer | DICOM “type” | Tag SOP Class UID (0x0008, 0x0016) (text or number, it seems to depend on how you read the DICOM) | Tag bval | Tag bvec | Comments -- | -- | -- | -- | -- | -- Philips | Classic DICOM | 'MR Image Storage' or '1.2.840.10008.5.1.4.1.1.4' | 0x18, 0x9087 | 0x18, 0x9089 |   Philips | Enhanced DICOM | 'Enhanced MR Image Storage' or '1.2.840.10008.5.1.4.1.1.4.1' | 0x18, 0x9087 or 0x2001, 0x1003 | 0x18, 0x9089 | Tags embedded in others tags One DICOM by sequence Siemens | Classic DICOM | 'MR Image Storage', '1.2.840.10008.5.1.4.1.1.4' | 0019 x 100c | 0x19, 0x100e |   Siemens | Enhanced DICOM | 'Enhanced MR Image Storage', '1.2.840.10008.5.1.4.1.1.4.1' | 0x18, 0x9087 | 0x18, 0x9089 | Tags embedded in others tags One DICOM by sequence– To check on example data GE | Classic DICOM | 'MR Image Storage', '1.2.840.10008.5.1.4.1.1.4' | 0x43, 0x1039 Slop_int 6 (ex: (0043, 1039) [Slop_int_6... slop_int_9] IS: [1000, 8, 0, 0]) | 0x19,0x10bb and 0x19,0x10bc and 0x19,0x10bd | Bvec relative to the frequency, phase and slice so not with reference to the scanner bore (as Siemens and Philips) . Need to be correted using the tag In-plane Phase Encoding Direction (0018,1312) —> see dcm2niix function https://github.com/rordenlab/dcm2niix/blob/master/console/nii_dicom_batch.cpp#L247

[montigno]

Hi @manuegrx,

Great for the table ! I will complete it if I have any other information.

I did not have time to modify mri_conv for the conversions of bevcs/bvals into FSL or MrTrix format.

I will watch all this after November 15.

See you soon !

[montigno]

Hi @manuegrx,

You will find in the 'devpt' branch, a beta version of mri_conv. Normally, the bvec vectors now respect the fsl format (image-based orientation) and the MRTrix format (scanner-based orientation). It remains to be tested on Dicoms from different manufacturers.

To be continued !

See you soon

[manuegrx]

Hi @montigno !

Thank you, I tested a little bit the devpt branch!

It seems fine for DICOM Philips:

• Phillips DICOM Enhanced --> ok for FSL format for .bvec and MRTrix format for .txt
• Phillips DICOM Classic --> ok for FSL format for .bvec and MRTrix format for .txt In both case it is not exactly the same round and not always the same positive/negative sign as dcm2niix and/or MRTrix mrconvert command but I think it is not an issue (dcm2niix and MRTrix do not have the same round and the same positive/negative sign either)

However, the devpt branch does not working with PAR/REC. No bvec/bval/mrtrix bvec bval files are created. It is as if mri_conv had not detected that this was diffusion data. It works with the same PAR/REC in the master version. Do you know why ?

[montigno]

Hi @manuegrx,

Effectively, it could not calculate the bvecs for fsl. It needs the rotation matrix calculated with the angles ap, fh and rl from PARREC. The axes of this matrix depend on the image type (sagittal, coronal or axial). To find the right axes, I will stick to the dicoms, so I will need the PARREC and Dicom from the same sequence, I have some of them, but if you also have them that would be good..

To be continued !

See you soon

[manuegrx]

Okay it explains why the .bvec and .bval files (in FSL format) are not present :)

But in my test the "-bvecs-bvals-MRtrix.txt" (in MRTRIX format) is also not created. As it is what it was already done before (and as it is correct) , I think we should keep it !

[montigno]

Hi @manuegrx,

You will find in the 'devpt' branch, an other beta version of mri_conv (24.1.1a) It now works for Philips. Nevertheless it remains to find the right directions of bval.

I will need Dicom and Philips of the same sequence

To be continued !

See you soon

[manuegrx]

Hi @montigno ,

Thank you, it works well !

[manuegrx]

@montigno I will ask if I can have the same sequence in DICOM and PAR/REC, I let you know