Checking successful conversion?


#1

Hello all,

I am attempting my first try at converting DICOM files to mif format along with .bvec & .bval files.
I am running the following command

mrconvert ~/Documents/DWI/Subj_01/011_DICOMimages -fslgrad ~/Documents/DWI/Subj_01/011_DICOMimages/Subj01.bvec ~/Documents/DWI/Subj_01/011_DICOMimages/Subj01.bval Converted_Subj01.mif 

I want to make sure if the above command is correct and if it will include the .bvec/.bval info in the outputted .mif file? Are there any other steps/options I am missing?

I would like to proceed with distortion corrections after this step. But do I run distortion correction on the outputted (Converted_Subj01.mif) file from the above step or use the original DICOM images? Additionally, I am bit confused about how to correctly use the topup/rpe command. I have 2 folders named “dti_b0_PA” and “dti_b0_AP” in my DWI directory. These folders contain files named from 0001.dcm - 0064.dcm. Have I written the command below correctly?

$ mrcat dti_b0_PA/ dti_b0_AP/ b0s.mif

I’m not sure how to modify the subsequent command given the folders mentioned in my DWI directory. Can anyone help me edit this one please?
$ dwipreproc 004_-_DWI_phaseAP/ dwi_preprocessed.mif -pe_dir AP -rpe_pair -se_epi b0s.mif [ -readout_time 0.1 ]

EDIT: including a snapshot of folders located inside DWI/Subj_01 directory.
30%20AM

If there’s any other information I can provide, please let me know.
Thank you in advance.


#2

OK, normally DICOM files should already contain the information about the DW encoding. What you’re trying to do here is to override that information with your own bvecs/bvals. I wouldn’t ever recommend that unless you know the DICOM is not to be trusted for some reason (maybe it’s not a product sequence?). Otherwise, I would always always consider the DICOM to be the reference source for that information – there’s just too many ways for the bvecs/bvals to become inconsistent with the data somewhere along the line…

On the other hand, if you were actually trying to extract the bvecs/bvals from the DICOM files, then the relevant option is -export_grad_fsl. But note that the mif format stores this information in its header, so there’s no need to extract the bvecs/bvals – unless you need them for some subsequent processing step in a 3rd party package. In this case, I’d advocate delaying this step until the moment you actually need it, in case something else happens that might modify the gradient table (dwipreproc for example), which mean the bvecs/bvals you extracted earlier are no longer current.

With the caveat that ‘correct’ depends on the above, yes. See the DW gradient handling page for full details.

Everything looks right to me. I’d also add the -axis 3 option to the mrcat call to make sure it concatenates along the right dimension. But other than that, I think it should just work. Have you tried it…?

Also, assuming these data were acquired on a Siemens system, and that you’re running an up to date version of MRtrix3, you could probably simplify this further by allowing MRtrix3 to use the PE direction information from the DICOM headers directly.


#3

Hello,

Thank you for providing the clarifications. I have a few follow up questions. I don’t mean to be a bother with tons of questions…this is my first attempt at working with DWI so I just want to make sure I understand steps correctly.

If I have access to all DICOM images of a subject, I do not need to extract or do any further steps with bvec/bval files because that info originally comes from the DICOM images itself?
So in the case of converting DICOMS, I would directly convert it to .mif (with the -rep_header command)?

What about converting .nii or .nii.gz files to .mif? Would I have to do something with the .bvec/bval files when converting .ni/.nii.gz files to .mif?

Edit: Including snapshot of DICOMimages folder and the files present there.
22%20PM

If I understand correctly, once DICOM images or .nii are converted to .mif, then the .bvec/.bval is contained in the header and moving forward, I don’t need to do anything with the .bvec/.bval file (unless I wanted to export it to use with another application)?

I didn’t understand what the 3 meant so I ommited that flag. But this command won’t be necessary if I’m converting DICOM images right? I’d just use the -rpe_header command?

Does this only work for DICOM images and not .nii/nii.gz?


#4

OK, there seems to be a bit of confusion here, I’ll try to clarify.

DICOM typically stores that information in its headers (at least the product sequences from the major manufacturers do). You can check yourself whether MRtrix3 can find this information using mrinfo your_DICOM_folder, e.g.:

$ mrinfo DICOM/
...
  dw_scheme:         0,0,0,0
  [21 entries]       -0.99949686000000004,-0.0050327100000000001,-0.0050327100000000001,1000
                     ...
                     -0.11020774999999999,0.27551937999999998,0.95513387000000005,1000
                     -0.031670320000000002,0.79175793999999999,0.57006572,1000 

shows a DW scheme with 21 entries, the first of which is a b=0, and the others b=1000 along different directions. Use the -dwgrad option to display the whole gradient table, by default you only see the first and last 2 lines.

The MRtrix3-specific mif format can also store this information. Again, use mrinfo to see if that information is present in any given mif file.

On the other hand, NIfTI (nii or nii.gz) files don’t store this information. It is typically stored as separate bvecs/bvals files. To analyse DWI data stored in nii format, you need to also provide the corresponding bvecs & bvals files – and it’s your responsibility to ensure that the information in those files is consistent with the data.

What all this means is that if you’re converting from DICOM to mif, the DW information will be transferred over. If converting from DICOM to nii, that information is lost – unless you explicitly request it be stored in bvecs/bvals files with the -export_grad_fsl option (available in many relevant commands, by the way, not just mrconvert). For the same reason, this also holds true if you convert from mif to NIFTI.

If you convert from NIfTI to mif with no other options, the DW information will not magically appear in the mif, the command has no knowledge of where you may have stored the DW scheme (or indeed, that you even have it available). So for this step, you need to manually provide them with the -fslgrad option, at which point mrconvert will insert the corresponding information into the mif header (again, you can check with mrinfo). As before, note that the -fslgrad option is available in all commands that process DW data, so you can always process your NIfTI data as-is – you just need to always provide the bvecs/bvals as well when you do so.

Our recommendations are to stick with the mif format throughout your processing pipeline, since we take great care to ensure that information is preserved and modified appropriately when necessary, without users needing to think about it. If you do need to deal with NIfTI at some point (maybe due to interactions with other packages), then we recommend you convert your data to NIfTI at that point, immediately before its use in the other package, to ensure the DW scheme is correct. Likewise, I’d recommend converting right back to mif when you’re done, to ensure the correct DW information remains as an integral part of that dataset, and guaranteed consistent.

If you use the -rpe_header option to dwipreproc, then you will most likely still need to use mrcat to concatenate the various images. See option 4 in this page. But in terms of what it means, it’s saying that you want to concatenate the images along axis 3, which is the 4th dimension (indexed from zero), i.e. the volume axis. If you’d requested axis 0, then you’d have got all your images concatenated along the x-axis, i.e. left to right, etc. If it’s not supplied, mrcat will guess which axis might be most appropriate, which will generally do what you expect, but I tend to state this explicitly anyway.

It works for (Siemens) DICOM and mif (if converted from said DICOM data), and not for NIfTI, for the same reasons as the DW scheme. That information is stored in some DICOM data (only Siemens, as far as we’ve been able to figure out), and can be stored in mif files too (look for pe_scheme entries in the mrinfo output). But as soon as you convert to other formats that can’t store this type of information, it will simply be discarded.

Hope this helps…


#5

Okay, to summarize…

  1. Converting DICOMs to .mif will automatically transfer & store info in the header - no need for -fslgrad option
  2. Converting .nii/.nii.gz to .mif won’t automatically transfer & store info in the header - have to use -fslgrad option for this
  3. Converting .mif to .nii/.nii.gz won’t transfer the info - have to use -export_grad_fsl option

For the PE direction, what would be the correct syntax/flag to use for …

  • .mif (converted from DICOMs)
  • DICOMs

Thank you for the patience with me & my questions regarding this.


#6

For the PE direction, what would be the correct syntax/flag to use for …

The specification of phase encoding direction for dwipreproc is not strictly dependent on the format of the input image: it depends only on whether or not the relevant information is available in the image header. If MRtrix3 is capable of determining such data from DICOM, then it will be present in any .mif image converted from that DICOM. If however you convert to NIfTI at any point (and don’t perform any other kind of metadata trickery), then such information will be lost due to the inability of that format to encapsulate such information, and hence it won’t magically re-appear in the image header by converting back to .mif.

Your acquisition looks like usage #2 on this documentation page. Usage #4 is also applicable, since your data should have the phase encoding information present. If you look closely at these two demonstrations, and appreciate the purpose of the -se_epi option (providing spin-echo EPIs that are to be used in estimation of the inhomogeneity field, but will not be included in the output image) and the -pe_dir option (providing the phase encoding direction manually when it’s not available from the image header(s)), you will hopefully see the equivalence.


#7

I will be converting straight from DICOM to .mif. In this case, I assume it would be appropriate to use mrcat <location_to_DICOMS> converted_from_DICOMS.mif -axis 3 ? This is my first time using MRTRix software so I don’t have many resources where I can ask questions/get help. It also happens to be my first try at analyzing DWI so I’m trying to be very careful in running preprocessing steps. At this point, I’m not too familiar with what ‘wrong’ things look like, ex-I won’t know for sure if a step has given the correct output hence all my questions before I start.

My main purpose for using this software is to look at specific tracts - especially the uncinate fasciculus. Given this, what would be the best prepare my DWI data to be able to get a good/correct analysis looking at specific tracts?

Does pre-processing pipeline look correct given I want to look at the tract uncinate fasciculus? Please feel free to correct me if I’ve gone wrong somewhere.

  1. Convert DICOMS to .mif (for ease of use)
  2. Run DWI Denoising
  3. Run Distortion Correction using DWI Preproc script (with option 4: Arbitrary phase encoding acquisition)
  4. Estimate Brain Mask
  5. Estimate Response Function
  6. Estimate Fibre Orientation Distribution
  7. Whole-brain streamlines tractography
  8. Track Density Imaging

Thank you in advance for any help!


#8

Your processing steps are all pretty standard & in the standard order.

mrcat <location_to_DICOMS> converted_from_DICOMS.mif -axis 3 ?

Whether or not that mrcat call is appropriate depends on which specific DICOMs you were referring to.

If a single series of DICOM volumes are all stored in a single directory, then that directory is considered to be a single image by MRtrix3; you do not need to “concatenate” the individual .dcm files within such a directory.

The purpose of the mrcat examples in the documentation page is if there is more than DICOM series that have been acquired specifically for the purpose of B0 inhomogeneity field estimation (017 and 018 in your case). Such images should be provided to the dwipreproc script via the -se_epi option. However this command-line option accepts only one input image; therefore all such volumes need to be concatenated into a single image series first.

You only have a single DWI series (011), and so no explicit concatenation is required in this case.


#10

EDIT: I’m running the dwidenoise command and getting the following error: Attaching text file since text is really long. dwidenoise_error.pdf (59.9 KB)


#11

There doesn’t seem to be much of a problem…? Your first attempt shows a warning and an error:

$ dwidenoise 011_nki_dti_30b_6b0_PA/ denoised
dwidenoise: [WARNING] Number of entries in mosaic slice timing (66) does not match number of images in mosaic (64); omitting
...
dwidenoise: [ERROR] unknown format for image "denoised" (no file extension specified)
dwidenoise: [ERROR] error creating image "denoised"

The error is purely about the lack of a suffix in the output filename to tell MRtrix3 what format to use for the output. Your second attempt seems fine, showing only the warning about an inconsistency in the slice timings. Once you strip out all of the debugging and information-level output, all you’re left with is:

$ dwidenoise 011_nki_dti_30b_6b0_PA/ denoised.mif -info -debug
dwidenoise: [done] scanning DICOM folder "011_nki_dti_30b_6b0_PA/"
dwidenoise: [100%] reading DICOM series "nki_dti_30b_6b0_PA"...
dwidenoise: [WARNING] Number of entries in mosaic slice timing (66) does not match number of  images in mosaic (64); omitting
dwidenoise: [100%] reformatting DICOM mosaic images
dwidenoise: [100%] preloading data for "AHB1038 (AHB1038) [MR] nki_dti_30b_6b0_PA"... 
dwidenoise: [100%] running MP-PCA denoising

which means it completed without error.

You typically get a large amount of debugging output when reading a DICOM folder since it reports on what it’s doing for each file in the dataset – and there’s typically a lot of them… But in your case, the only issue here is a minor warning about failing to import the slice timings, which is a very rarely used piece of information (typically required for fMRI, but in our case fed through to eddy’s new slice-to-volume correction).