Tractography error with Philips scanner

[brc0520]

Hello. We used deterministic tractography on our DTI data (taken from a Philips scanner) to generate muscle fibres in the lower limbs. The fibre tracts of our first roughly 150 scans which were scanned before August 2021 were okay. We found that the orientation of the fibre tracts after August 2021 were implausible despite that the scan protocols between participants were the same. Did anyone had this issue before? We don’t really know why at this stage, was hoping someone has faced this issue before.

We noticed that the Philips software was updated from 5.6.1\5.6.1.1 to 5.7.1\5.7.1.2 in August 2021 (still not sure if this was the reason. we will need to investigate this). We are currently using the latest mrtrix version as shown below.

Here’s what we have investigated:

1. We tried using both .mif and .nii+fslbvecs separately. Both methods were reproducible.
2. We checked the raw gradient directions and the fsl bvecs between participants, before and after that date. The orientation of the raw gradients (with respect to the scanner coordinate system) between participants were different. The orientation of the fsl bvecs (with respect to the image axes in LAS coordinate system) between participants were the same.
3. The x-axes of the fsl bvecs (in LAS format) for all the participants were being flipped when compared to the original vector scheme (which was in LPS format in patient coordinate system). Should we expect the y-axis being flipped instead?
4. We recently conducted separate investigation scans by using the same DTI protocol but with various stack angulations. We started with a scan with zero angulations in all the 3 planes (ie all 3 field of views being aligned with the scanner) and some other scans with one or all of the planes being rotated. All the scans including the aligned scan did not give plausible results. We also looked at the raw primary tensors before fsl topup (as in without any motion or eddy current corrections), they all looked very differently orientated, despite no obvious motions and the scans were taken on the same day.
5. We were not able to use the dwgradcheck method because it was not designed to deal with muscle architecture.
6. We checked the raw DTI scans between participants, there were no obvious artefacts.

Are we missing anything? Could someone suggests if there are other ways to troubleshoot this? Appreciate it.

[brc0520]

Adding to the comment on point 3. We are now certain that the directions in our data before and after August 2021 were consistent.

The directions in the original opt12 scheme (given before the start of the scan, Philips calls this scheme in the rotated MPS frame) were in RAS format with reference to the image coordinate system. This is the same direction scheme we used for all our participants.

The directions in the Dicoms were in LPS format (Philips calls this LPH in the patient frame) with reference to the real/scanner/patient coordinate system (more accurately defined as the patient coordinate system because we were using FFS: Feet First Supine orientation). This explains why the directions in the dicoms between our participants were different, as each scan was angulated differently.

Our fsl bvecs converted by dcm2niix (default setting) and mrconvert (stride -1,2,3,4) were in LAS format with reference to the image. This explains why the x-axes of our fsl bvecs were flipped when compared to the directions in the opt12 scheme (RAS), and why the directions between our participants were the same.

All this to say that we have checked the orientation and flipping of axes in these various formats. They were all correctly transformed within a participant and were consistent between participants. Despite consistency in the bvecs and the image protocol between participants, we are still seeing incorrect orientation of tensors and tracts for scans done after August 2021.

For point 4: We posted a separate detailed summary of our investigation scan here: Inconsistent primary eigenvector orientation in differently angulated scans of the same subject

[jdtournier]

Hi @brc0520,

Thanks for all the work you’ve put into your reports on the issue – I wish all our requests for support were that detailed!

I’ve been following your posts, but haven’t responded yet as I don’t think I have anything particularly helpful to say at this point. It feels like a scanner software issue (it wouldn’t be the first time…), but your latest post seems to suggest otherwise.

To recap:

• Philips should and has historically always stored their DW directions in the DICOM output with respect to the DICOM patient-centered coordinate system, regardless of how they may have been originally specified (itself quite a mess: MPS normally, unless Overplus was used, in which case it was scanner XYZ).

• bvecs/bvals are stored with respect to the image axes (with a potential x-axis flip if the image axes form a left-handed coordinate system – caught us out a while back)

• MRtrix internally stores and handles the DW directions with respect to the NIfTI frame (which will normally coincide with the DICOM patient-centered coordinate system, with the y & z axes reversed).

If you introduce different image angulations, then the DW directions in the DICOM (and internally within MRtrix) will change if they had originally been specified with respect to image MPS, but not if they had originally been specified with respect to scanner XYZ. Conversely, the bvecs will not be affected in the former case, but will change in the latter case.

If everything remains consistent, there should be no problem, and the orientations should be correct with respect to the anatomy – as long as there is no mixing between the different conventions. Issues can and most likely will be introduced by e.g. producing tensor eigenvectors in FSL and expecting them to display correctly in MRtrix (different convention on that front too!).

If you find that running a direct DICOM → tensor → eigenvector pipeline all within MRtrix produces inconsistent results, then we’ll need to investigate whether that’s due to a bug in our DICOM handling or in the latest version of the Philips software… Try a command such as this one to do this:

dwi2tensor DICOM/ - | tensor2metric - -vec - | mrview DICOM/ -fixel.load -

If that still shows inconsistencies, then I’ll probably need to take a closer look at the data…

[brc0520]

Hi Donald,

Thanks for your reply. Bear with me as I try to explain what we know so far.

I agree that the directions defined in philips can be confusing because they depend on the scan setting (e.g. gradient overplus, input file, or mps file, etc). In our case, I’m certain that all the directions (opt12 and directions in DICOM) in our scans before and after August 2021 were consistent. Our scan protocols were consistent: We inspected the exam cards. We used classic dicoms. The private tags were consistent: (2005,1563) = sagittal slice order = LR, (2005,1564) = coronalsliceorder = PA and (2005,1565) = transversalsliceorder = FH. This suggests our MPS directions were in RAS+; The transformations from opt12 (with respect to image axes) to the directions in DICOM (LPS+ = with respect to the patient-centered coordinate system) were consistent: I figured the rotation sequence from the investigation scan and applied it on our previous angulated scans. In mrtrix, the dw_scheme was in RAS+ (with x and y axes flipped); The bvecs/bvals in LAS+ were consistent: All our participants gave the same bvecs/bvals (with the x-axis flipped).

Then, I started comparing the DICOM headers to see if they were the same. 3 things were inconsistent. First, the number of fields in the DICOM changed after the software updated. Second, the rescaleslopetag (0028,1053) were inconsistent. Third, the philipsscaleslope tag (2005,100E) were inconsistent. See the timeline below. Could this trigger something? This suggest that the dicoms before and after August 2021 were inconsistent despite the same scan protocol.

Another related finding is that the dicom viewer of the dsistudio sees the dicoms before and after August 2021 differently, although we did not find any obvious issue in mrtrix as well as dcm2niix (by Chris Rorden). Its confusing here because dsistudio sees our more ‘accurate’ scans wrongly. Anyway, this suggests that the dicoms may have been stored differently. Earlier, mrtrix had slice sorting issue but this has been resolved in the latest release: Problem with sorting of DICOM images using mrconvert (thanks for that!)

If you find that running a direct DICOM → tensor → eigenvector pipeline all within MRtrix produces inconsistent results, then we’ll need to investigate whether that’s due to a bug in our DICOM handling or in the latest version of the Philips software… Try a command such as this one to do this:

With regards to your suggestion to reconstruct primary eigenvectors directly from the DICOMs, here are the results:
To recap, we conducted an investigation study comprised of 4 DTI scans: one not-angulated scan (ie with the image axes aligned with the scanner), one with a +20 degr rotation around the RL axis, one with +20 degr rotation around the AP axis, and one with rotations applied in all 3 planes (which is how we typically obtain for our scans): +7degr around RL axis, -2.84 degr around AP axis and +16.5 degr around IS (or philips calls this PH) axis. We exported classic dicoms, par/recs, enhanced dicoms and xml/recs.

Tensors and tracts from the PAR/RECs and ENHANCED DICOMs appeared consistent with those from CLASSIC DICOMs. However, one thing worth knowing is that the private tags (0018,9075) = Diffusion Directionality in all the files in CLASSIC DICOM were shown as ‘NONE’ whereas these tags were different in the files in ENHANCED DICOMS (ie it was shown as ‘NONE’ for the b0 slices and ‘DIRECTIONAL’ for other slices containing gradient directions).

Below, I show one scan (on the left column) conducted before August 2021. Typically, we would expect to see the fibre tracts with respect to the aponeurosis (shown as dark voxels) to be angled roughly this way. If you compare it with the not-angulated scan, you can see that the tracts of the not-angulated scan were somewhat straighter. So even the not-angulated scan was already giving us a problem.

Here, I compare primary eigenvectors between the 4 scans. You can see very clear differences in orientations despite they were scanned on the same person and on the same day.

FYI, our engineers ran some QC checks on the hardware including the coil but did not find anything unusual. We are hoping its a software bug though. Fingers crossed.

To summarise, we saw consistent directions between participants but there were inconsistencies in image scaling and DICOM handling. Could it be a software bug somewhere? We are happy to share our data if it helps. Please let us know.

Cheers, Brian

[jdtournier]

Hi Brian,

I think the only way we’re going to figure this out is by looking at the data… If you could share some with me, that would be great.

Thanks!
Donald

[brc0520]

Thanks Donald! I have emailed a shared link containing some data to your gmail at jdtournier@gmail.com. Please let me know you need anything else. Appreciate your time and help.

Cheers, Brian

[brc0520]

Hi everyone,

I have personally updated Donald about this issue. I thought it will be nice to also briefly update it here so that anyone following this post will know as well. We don’t have the full picture at the moment as we are still investigating the matter. Long story short, we are convinced that our affected scans were not due to mrtrix but were likely due to a software bug in the pre-release Philips software that was patched sometime in August 2021. With that, I would like to end this post by expressing our since thanks to Donald, Kurt and the mrtrix team for being very helpful in our investigation. Thank you guys!

Brian