The orientation of tensor fitting by dwi2tensor

Qi_Yang · January 13, 2021, 7:11am

Dear expert of MRtrix3,

I like MRtrix very much. It is very useful thanks to the effort made by your guys. But I have a question which bothers me a lot. I am not sure do you guys know TORTOISE , a package used to make preprocessing and tensor fitting. I notice one interesting. I use same image, b-values and gradient table to fit tensor and visualize them. But I notice that in tensor orientation is not correct in MRtrix. But in TORTOISE, it is right. I am not sure why this happend. I am not is that related with the direction defined in MRtrix or anything else ? It would be great if anyone can give me the hint about that! Below is the tensor visualization with two different software. dwmri_proc_DRBUDDI_up_final_N1_DT_1_51|500x500

jdtournier · January 13, 2021, 9:17am

Hello and welcome!

Just to clarify, can you confirm how the results you’re showing were produced:

entirely using MRtrix tools, starting from the raw DICOM data?
converted from DICOM to NIfTI using some other tool, then processed within MRtrix thereafter?
preprocessed using TORTOISE with the tensor fitting produced with MRtrix’s dwi2tensor?
preprocessing and tensor fitting all performed in TORTOISE and the results visualised in MRtrix’s mrview?

If (1), then we need to figure out where the DICOM import might have gone wrong.

If (2) or (3), then I would take a close look at the tools used for the conversion, and verify the conventions assumed by TORTOISE. There’s many places where things can go funny – we’ve certainly been bitten by unexpected issues of this nature in the past… But I’m pretty sure we’ve sorted out all the problems now …

If (4), this may be due to the tensor elements being stored assuming different conventions for the coordinate system. In MRtrix, orientations, tensor elements, spherical harmonics, etc. are all stored with respect to the scanner/world coordinate system, not with respect to the image axes (as may be the case with other packages). I’ve no idea what convention TORTOISE might assume here.

If you can clarify which of these we’re talking about, we might be able to narrow things down further.
All the best,

Donald.

Qi_Yang · January 13, 2021, 1:23pm

Hi Donald,

Thanks for your quick response. Currently the following text is the my understanding for your questions.

Currently, I preprocess image with TORTOISE from NIFTI image to preprocessed diffusion image (not tensor). I think NIFTI image is converted from DICOM by dcm2niix. Then, the preprocessed image is used to fit tensor by TORTOISE and MRtrix respectively. Currently, I notice that TORTOISE can handle image, gradient table and b-value correctly, which can be demonstrated from tensor visualization from image. It work as expected. But if I use Mrtrix dwi2tensor and mriview to visualize tensor, I notice that tensor is not aligned well with b0 image. I guess MRtrix might use different way to handle image direction, b-values and gradient table.

The above part is what I think now. If you need further details and need me to clarify something, please let me know.

Thanks,
Qi

jdtournier · January 13, 2021, 1:43pm

Hi Qi,

Thanks for the clarifications. My best guess here is that this might have something to do with a quirk in the handling of the bvecs when the image is stored assuming a left-handed coordinate system (qfac > 0, sometimes referred to as ‘neurological convention’). This has caught us out in the past, but we have since taken great care to match the expectations of FSL exactly (details in this post).

To verify this, could you report the output of:

mrinfo dwi.nii

Substitute the name of your DWI data (as provided to the tensor fitting routine) instead of dwi.nii.

Then, assuming the above shows the strides are listed as 1,2,3,4 or -1,2,3,4, try the following (again, substitute dwi.nii with the correct filename):

mrconvert dwi.nii -stride 1,2,3,4 dwi_A.nii
mrconvert dwi.nii -stride -1,2,3,4 dwi_B.nii

Process both of the resulting datasets (dwi_A.nii and dwi_B.nii) using your tensor fitting and display pipelines (TORTOISE & MRtrix), and see whether the results match expectation. Both data sets should produce the correct answer without modifying the corresponding bvecs (this is what caught us out in that previous issue I linked to above).

Qi_Yang · January 13, 2021, 3:28pm

Hi Donald,

In the following text, I will use A to represent image whose stride is [1,2,3,4] after mrcovnert. Orig represents original image. I will use B to represent image whose stride is [-1,2,3,4] after mrconvert. The tensor visualization is shown in the following image

. I notice Orig and A for TORTOISE is correct but B is not correct. And Orig, A and B doesn’t work with MRtrix. I am not sure do I do something wrong ? The following is the mrinfo for Orig image.

Image name: “dwmri_proc_DRBUDDI_up_final.nii”

Dimensions: 68 x 102 x 102 x 61
Voxel size: 2.5 x 2.5098 x 2.5098 x 1
Data strides: [ 1 2 3 4 ]
Format: NIfTI-1.1
Data type: 32 bit float (little endian)
Intensity scaling: offset = 0, multiplier = 1
Transform: 1 0 -0 -84.5
0 1 -0 -127.5
0 0 1 -127.5

Is there anything you need to investigate this question, please let me know

jdtournier · January 13, 2021, 4:05pm

Thanks for taking the time to do this, it’s appreciated.

OK, assuming the top row is TORTOISE, and the bottom row is MRtrix, the issue matches what I expected. It’s far from trivial unfortunately, due to the idiosyncrasies of the bvecs/bvals format. The main issue relates to this small, but important addition to the FSL wiki where they describe how to interpret these files (my emphasis):

The bvecs use a radiological voxel convention, which is the voxel convention that FSL uses internally and originated before NIFTI (i.e., it is the old Analyze convention). If the image has a radiological storage orientation (negative determinant of qform/sform) then the NIFTI voxels and the radiological voxels are the same. If the image has a neurological storage orientation (positive determinant of qform/sform) then the NIFTI voxels need to be flipped in the x-axis (not the y-axis or z-axis) to obtain radiological voxels.

An image stored with strides 1,2,3,4 is stored using the standard NIfTI coordinate system, which is ‘neurological’ (positive qfac / positive determinant of the qform/sform) – whereas an image with strides -1,2,3,4 is ‘radiological’ (note that I really dislike the use of these terms in this context, I would normally use neurological & radiological to refer to the display of the images only, not how they’re stored on disk). This means that the x component of the bvecs needs to be flipped (inverted) if the image it relates to is stored this way.

Unfortunately, as far as I can tell, this means that the data passed to TORTOISE is not actually compliant with FSL – it would be good if you could confirm that by running FSL’s dtifit and looking at the results in fslview or fsleyes. I’m pretty confident our bvecs handling is consistent with FSL (which is the reference implementation for that format), so I think the issue here is that TORTOISE is not handling these files as required. It would be good to confirm this against FSL and report the issue to the TORTOISE developers.

Given that these data were converted using dcm2niix, I’d also recommend getting @Chris_Rorden’s opinion as to what might be going on here. As I understand it, dcm2niix doesn’t try to reorder the data, so I would expect the images produced to have strides -1,-2,3,4 – corresponding to their ordering in the original DICOM data. I suspect some other operation has been applied to the data to reorient it to the standard NIfTI frame, was this the case? In which case, there’s the possibility that this operation might have introduced some discrepancy here?

neurolabusc · January 13, 2021, 8:52pm

@jdtournier your comments reflect my views. By default, dcm2niix will typically convert Axial scans as LAS (e.g. first voxel on disk is right/posterior/inferior corner of scanner space, with fastest [columns] increment being leftward, then anterior [rows] and finally superior [slices]). As you describe, the FSL bvec format is unintuitive but consistent. Most (but not all) FSL tools seem to demand that a volume has a negative determinant, and if this is not the case the column order is mirrored (resulting in a negative determinant).

I have to say that I am not familiar with TORTOISE, and so you may want to contact that group. Perhaps since it is from the NIH it is also expected that you run the AFNI @gradfliptest. As I understand it, AFNI ignores the determinant of the image, so it does not technically support the FSL format bvec files created by dcm2niix. However, the dradfliptest exhaustively searches the possible permutations and selects the best fit, providing a clever method to handle FSL bvec files in practice.

@Qi_Yang it might be worth going back to the source DICOMs. You mention I think NIFTI image is converted from DICOM by dcm2niix which does not exude confidence. The dcm2niix wiki includes a link to a dedicated document in Word format that describes how to acquire validation datasets. You can then run the datasets through FSL, AFNI, Tortoise and MRTrix to determine what is going on. Failing that, the wiki provides links to download validation datasets acquired with each major manufacturer.

jdtournier · January 13, 2021, 9:03pm

OK, good to hear. And yes, that should be maximally compatible with FSL.

For completeness, MRtrix includes a similar method in the dwigradcheck script – based on @bjeurissen’s MIA 2014 paper. I also reckon this might be worth using here – though I personally prefer to know that the conversion was done properly, rather than have to rely on this type of post-hoc correction. But these approaches are definitely great for investigating what’s going on!