How to extract .bval and .bvec from DTI DICOM file?

[Sunita2023]

Dear DIPY forum members,

Trial 1:
We having problem in extracting .bval and .bvec values from DTI DICOM image. Dimension of DTI DICOM file is 128x128x80x34. There are a total of 2720 .dcm files (DICOM). The DICOM tag used to filter .bval is "(0018, 9087) Diffusion b-value" and .bvec is "(0018, 9089) Diffusion Gradient Orientation". When we extracted these values there are 2720 .bval and 2720x3 .bvec values.
To generate fiber tracts we need 34 values saved in .bval file and 34x3 values saved in .bvec file.

Could you please help us to get .bval and .bvec values so that we can generate fiber tracts.

Trial 2:
We also tried using dcm2niix to extract .bval and .bvec values from DTI DICOM files using following code line.

!dcm2niix -z y -f myMRI%s -o "./New" "./DTI_HIGH_1000"

This command didn't generate .bvec and .bval files but gave following warning.

Warning: GEIIS violates the DICOM standard. Inspect results and admonish your vendor.

Could you please help us to generate .bval and .bvec files from DTI DICOM file.

We are stuck in this problem from last few days.

Your help will be highly appreciated.

Thank you so much.

Best regards,
Sunita

[skoudoro]

Hi @Sunita2023,

Look like a question for the neurostar forum (https://neurostars.org/). You will have a better chance to get answer concerning DICOM. there is the creator of dcm2niix in this forum.

Maybe @arokem has an idea?

[Sunita2023]

Dear Ariel,

We are using dcm2niix to extract .bvec and .bval file. However unable to generate these files as it is giving above warning message.
Could you please guide to solve this issue. Being a developer of dcm2niix you are the best person to answer the question.

Thank you so much in advance for your help.

Best regards,
Sunita

[arokem]

I am not a dcm2niix developer, but I saw that you also posted on neurostars, which hopefully will reach the developers of that software.

Do the b-values and b-vectors that you got from dcm2niix happen to be repetitions of the same values? It looks like you have 80 times as many b-values and b-vectors as you had expected, so I am wondering whether it's simply producing a multiplicity of the correct values.

Also, I imagine that you already found this post? Looks like you need to adapt the way that the GE PACS is extracting these images going forward.

[ShreyasFadnavis]

Hi @Sunita2023 !

I just wanted to share an observation from your Trial #1: 2720 = 80 x 34. This suggests that you might not need to extract a b-value and b-vector for each of the slices.

Perhaps the 34 b-values and the corresponding 34 x 3 b-vectors are already present, simply repeated 80 times for each gradient direction?

[Sunita2023]

We tested on DTI hardi data. We extracted .bvec applying both methods.

Method 1 using dcm2niix
The .bvec values (3,62) are as follows

0 0.109692 -0.165889 0.240716 -0.717897 0.786921 0.836264 0.591334 0.0461773 -0.930029 -0.231583 -0.314705 0.6937 -0.546271 -0.937137 0.362776 -0.343256 -0.284252 -0.645103 0.621003 0.615309 0.958568 0.277754 -0.782946 0.125729 0.764113 0.51558 -0.237675 0.323931 -0.351688 -0.998521 -0.379955 -0.444132 0.869509 0.154179 -0.790135 -0.843747 0.0200954 0.019695 0.631918 0.433744 -0.466809 -0.807494 0.21448 -0.562189 0.807255 0.0673332 -0.954685 -0.369038 -0.0845265 -0.61287 -0.908219 0.537939 0.503125 0.00794281 -0.275518 0.936269 -0.0724347 -0.753475 0.638618 0.362542 -0.558332

0 -0.978568 -0.394989 0.686377 0.535858 0.59931 -0.000244662 -0.664329 0.180174 -0.0392682 0.906263 -0.819194 0.604477 0.0870829 0.3484 -0.25681 -0.930513 0.563263 -0.41509 0.204393 -0.779987 0.150568 -0.726153 0.208238 0.900319 -0.355741 0.838165 -0.0456405 0.382114 0.935427 0.0365598 -0.58398 0.715363 0.468368 -0.500063 0.601507 -0.368013 -0.882541 0.499349 -0.136259 0.793669 -0.243924 0.533868 0.974871 0.407965 0.320185 -0.160046 -0.28153 0.867848 0.77185 -0.660676 0.294111 0.521222 -0.485404 0.991913 0.274526 -0.184768 -0.69231 -0.110498 0.761025 0.064787 0.792896

0 0.174274 0.903584 0.686253 0.444387 -0.146912 0.548326 0.457156 0.98255 0.365382 0.353634 0.47946 0.391647 0.833069 -0.0197972 0.895791 -0.127753 0.775845 0.641516 0.75669 0.114081 0.24182 0.628931 0.586202 0.416676 0.538126 -0.177925 0.970272 0.865481 0.0359548 0.0402379 0.717358 0.539446 0.156796 0.852154 0.117797 0.390713 0.469806 0.866177 0.762963 0.426564 0.850053 -0.250876 -0.0602116 0.71938 0.495804 0.98481 0.0965243 -0.332642 0.630161 0.433473 0.297719 0.662533 0.715016 0.126675 0.921263 0.298766 0.717956 0.648125 0.11405 0.929713 0.244094

The .bval (62) values are
0 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000

When we used method 2 that extracting from "(0018, 9087) Diffusion b-value" and .bvec is "(0018, 9089) Diffusion Gradient Orientation"
we got following .bvec values.

0.0, 0.06599932163953781, -0.19789382815361023, 0.25689244270324707, -0.7027528882026672, 0.813518762588501, 0.8258129954338074, 0.555219829082489, 0.03639901056885719, -0.9371088147163391, -0.20000019669532776, -0.3567071855068207, 0.711182177066803, -0.5566902160644531, -0.92141193151474, 0.3360963463783264, -0.3792145252227783, -0.27421101927757263, -0.6728692650794983, 0.6155984997749329, 0.5803838968276978, 0.959602952003479, 0.23639050126075745, -0.7837873697280884, 0.15560047328472137, 0.7391886711120605, 0.5528879761695862, -0.25630447268486023, 0.32428494095802307, -0.3132167458534241, -0.9967010021209717, -0.41631224751472473, -0.4234931766986847, 0.8852853178977966, 0.11839793622493744, -0.7664831876754761, -0.8649742603302002, -0.024700572714209557, 0.025199975818395615, 0.6122835278511047, 0.4587138295173645, -0.491316020488739, -0.7801740765571594, 0.2556954622268677, -0.5573114156723022, 0.8110237121582031, 0.04340231418609619, -0.9670695662498474, -0.3268977701663971, -0.0634990930557251, -0.6471999883651733, -0.9003283977508545, 0.5473891496658325, 0.4699987769126892, 0.04680235683917999, -0.27999091148376465, 0.9224406480789185, -0.11360038816928864, -0.7686316967010498, 0.667497456073761, 0.3485889136791229, -0.5291974544525146

0.0, 0.9963898062705994, 0.4954845607280731, -0.5857827663421631, -0.5077382326126099, -0.5782132744789124, 0.10380163043737411, 0.7404264211654663, -0.05589846521615982, 0.0436004139482975, -0.8651008605957031, 0.8575173616409302, -0.5211869478225708, -0.0075998688116669655, -0.3884049952030182, 0.3803958296775818, 0.8920341730117798, -0.4754191040992737, 0.4624788463115692, -0.08279979228973389, 0.8139774203300476, -0.07810024917125702, 0.809267520904541, -0.16829729080200195, -0.8360025882720947, 0.4518930912017822, -0.8305818438529968, 0.15420269966125488, -0.2584880292415619, -0.9382501244544983, -0.07450007647275925, 0.650719165802002, -0.6621893048286438, -0.4074932634830475, 0.607189416885376, -0.6160865426063538, 0.3763887882232666, 0.9336215853691101, -0.3877996504306793, 0.2561931014060974, -0.7157215476036072, 0.3261106312274933, -0.5950801968574524, -0.964682936668396, -0.34040704369544983, -0.22160649299621582, 0.2826150357723236, 0.2496921420097351, -0.9172937273979187, -0.6914900541305542, 0.6818000078201294, -0.29430925846099854, -0.41209179162979126, 0.5908983945846558, -0.9675487279891968, -0.17089444398880005, 0.26041147112846375, 0.771502673625946, 0.15660646557807922, -0.7128972411155701, 0.06569791585206985, -0.780296266078949

0.0, 0.053399451076984406, 0.8457736968994141, 0.7686773538589478, 0.4983374774456024, -0.06210143491625786, 0.5543087124824524, 0.3788135051727295, 0.997772753238678, 0.3463032841682434, 0.4600004553794861, 0.3707074820995331, 0.4717881679534912, 0.8306853771209717, 0.011900153011083603, 0.861590564250946, -0.2459094077348709, 0.8359335660934448, 0.5773735642433167, 0.7836980819702148, 0.024399319663643837, 0.27030083537101746, 0.537778377532959, 0.5977904200553894, 0.526201605796814, 0.4993923306465149, -0.06669854372739792, 0.954216718673706, 0.909957766532898, 0.14690785109996796, 0.03220003470778465, 0.6350186467170715, 0.6181899905204773, 0.22409628331661224, 0.7856862545013428, 0.1814960390329361, 0.3318901062011719, 0.3574082553386688, 0.9213991761207581, 0.7479799389839172, 0.5266158580780029, 0.8076263666152954, -0.1928935945034027, 0.06329888105392456, 0.7573156356811523, 0.5414158701896667, 0.9582509994506836, 0.04929844290018082, -0.22739845514297485, 0.7195896506309509, 0.340999960899353, 0.3206101059913635, 0.7283855676651001, 0.655698299407959, 0.24831250309944153, 0.9446693658828735, 0.28511255979537964, 0.6260021328926086, 0.6202255487442017, 0.21499918401241302, 0.9349703192710876, 0.33329838514328003

The .bval values are
0 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000

In second method .bvec values are repeated after every 62 values.

Why there is a difference between the .bvec values extracted using dcm2niix and manual method?

Kindly please guide.

Your help will be highly appreciated.

Thanks a lot.
Sunita

[Sunita2023]

Dear DIPY members,

Could you comment on why we are getting different values of bvec from the same DICOM file.
Your comments and suggestions would be of great help to us.
Thank for your help.
Best regards,
Sunita

[skoudoro]

To give more info to other users/devs, I copy/paste the answer by @neurolabusc from neurostar(https://neurostars.org/t/how-to-extract-bval-and-bvec-from-dti-dicom-file/29433)

I can not provide much more feedback without seeing the data - if possible you can share them with my institutional email. It is worth knowing that the answer depends on your vendor. Since your data does have the public tag 0018,9089 it should be possible to convert these to FSL/BIDS format bvec files. There are two important concerns. The first concern is that the DICOM tags report data in world space, while the FSL/BIDS format requires these to be in image space, so if your images are angulated relative to the scanner bore you will need to rotate the vectors accordingly. Also, be aware that the FSL/BIDS format assumes the NIfTI images have a negative determinant and will swap the first dimension (columns) on disk to ensure this. Therefore, if your NIfTI data has a positive determinant you will want to swap the first component of your bvec file.

I would check you are using the latest generation of dcm2niix (v1.0.20240202) 1. It appears to think that your images were touched by an old GEIIS PACS system which added a image icon that did not conform to the DICOM standard. The issue here is that when subsequent servers touch these, or tools try to anonymize these, the resulting DICOMs can become corrupted in strange ways. The best thing to do is check the provenance of your images, and get a copy before they have been touched by the GEIIS PACS. If this is not archival data, make sure your GEIIS PACS system is upgraded to meet DICOM conformance.

Personally, I do not have an answer, I did not spend enough time with DICOM.

[arokem]

Same here: no idea.

[neurolabusc]

@Sunita2023 the sample dataset you sent me was corrupted. You can see this by using any tool to view the DICOM header. For example, use dcmdump or gdcmdump to view the header of the DICOM file Anonymize 13.04.2024.Seq11.Ser901.Img229.dcm which gives non-sensical values:

(0002,0010) UI =LittleEndianExplicit                    #  20, 1 TransferSyntaxUID
(0018,9087) FD 2.0903798899788137e-317                          # 8,1 Diffusion b-value
(0018,9089) FD 1.3630448616603177e-312\3.4030905003077931e-312  #  24, 3 DiffusionGradientOrientation

It is worth noting that the hex code 0x408F4000 00000000 is a non-sensical little-endian 2.0903798899788137e-317 but is the expected 1000 if one ignores the transfer syntax and treats it as big endian. This image has been touched by a lot of tools including a dreaded GEIIS PACS that is known to insert a thumbnail image into DICOMs that is not valid DICOM and often trips up the next tool that touches the image (as well as a savage anonymization tool). My best guess is that at one stage this image had the correct values saved as big endian (perhaps implicit) and another tool saved the data as little-endian but did not byte swap the crucial tags.

A basic premise of dcm2niix is that it assumes that the DICOM images are truthful. This is not the case with this dataset. The solution is to check the provenance of these images and convert a copy of the DICOMs before it was corrupted.

One of your subsequent posts describes a situation where the bvec values reported by dcm2niix differ from 0018, 9087. This is the expected behavior. The public tag 0018,9087 defines gradient direction in the patient's world space, while the bvec format requires vector directions to be reported in image space. Therefore, the gradient components will only have the same amplitude in DICOM and NIfTI if the scan was acquired orthogonal to the scanner bore. Therefore, to convert from DICOM to NIfTI you must:

1. swizzle component order if the image is not acquired with axial slices.
2. transform world space with the images spatial rotation matrix.
3. Swap the polarity of the first component if the NIfTI image has a positive determinant.

As I note in the dcm2niix manual you can always validate your b-vectors to ensure they have been converted correctly.

[Sunita2023]

Thank you so much Chris for the brevity and clarity in your answer.
I have few more questions.

1. How to check the acquired image plane? Is there any DICOM tag to look into?
2. Transformation of patient's world space into image space. Need bit of your guidance on how to do it. How to get world space matrix and image space matrix to which former will be converted?
3. NIfTI image has a positive determinant or negative determinant. How to check that?

Sorry, I am asking questions that might be trivial for you. However, without knowing this I can not proceed further.

Could you please guide Chris?

Best regards,
Sunita

[neurolabusc]

dcm2niix is open source with a permissive license. Feel free to examine its code and port it to the language of your choice.

1. You can determine the image plane of a DICOM slice from the Image Orientation tag (0020,0037).
2. You can use the DICOM image orientation tag (0020,0037) to determine the orientation of a 2D plane. Use the DICOM image position (0020,0032) tag from two neighboring 2D slices to determine the slice thickness and slice direction. Taken together, this gives you a 3D spatial transformation matrix. Transform this matrix to convert from DICOM to NIfTI space. This will be your NIfTI SForm.
3. Compute the volume of a voxel using the NIfTI SForm - if the volume is negative the image has a negative determinant, if it is positive it has a positive determinant.

[Sunita2023]

Hi Chris,

I'm sincerely grateful for the guidance you've provided. Thank you so much.
Finally dcm2niix is working on another patient data. It seems problem is there in previous data as you pointed out. In this new data bval values are 0,1000.... not like the previous case.

Now the raw DTI data we have having. Normally what are the preprocessing steps one should do before extracting the FA values?

I would like to appreciate and congratulate the forum for been so helpful and precise in answering the queries.

I am really grateful to be part of it.

Thanks again.
Sunita

[arokem]

Hi Sunita - for preprocessing, you might want to look into qsiprep, which is a DIPY-powered BIDS app pipeline that does end-to-end preprocessing of diffusion MRI data. You can read about the steps in that project's documentation.

@neurolabusc : this is a "discussion", so no need to close it.

[neurolabusc]

@Sunita2023 it sounds like we have resolved your problem, so I suggest you close this issue. With regards to processing DTI data to extract derived metrics like FA, AFNI, FSL (dtifit), MRtrix and dipy all have capable solutions. While I am a user of these tools, I am not an expert and so your question is outside my domain.