Dw_scheme - dicom import or -fslgrad & -json_import

You can download the dicom (DWI_MB3_DIR64_RL_0003) for the RL phase encode direction from here.

I looked at the DICOM header using OsiriX Lite and did not find the Anatomical Orientation Type (0010,2210) Tag so I think it is not specified and therefore BIPED.

I do not have a dataset with both an image oriented with the scanner bore and another where a rotation is applied. Presuming I understand this correctly, we pretty much always have some rotation to achieve ACPC like images. I am happy to commit to acquiring a validation dataset (BIPED and QUADRUPED for rotated and non-rotated) but I will not be collecting data until March 2019. I will try and ask for it to be done before but


I think it worked correctly - orientation labels are correct and vectors look coherent. Here is a screenshot and I put a reoriented FA map and dec_dicom_reoriented.mif here if you feel the need to check them :slight_smile:

Thanks to both (@jdtournier & @Chris_Rorden) of you, I really appreciate your time!
Scott

Yep, that looks right to me too. Thanks for confirming! :+1:


Confirmed, no such tag shows up using dcminfo either. And absence of that tag defaults to biped, according to the standard:

If Anatomical Orientation Type (0010,2210) is absent or has a value of BIPED, the x-axis is increasing to the left hand side of the patient. The y-axis is increasing to the posterior side of the patient. The z-axis is increasing toward the head of the patient.


Also, a quick rummage through the DICOM header reveals that the positioning wasn’t the typical head-first supine, but head-first prone (i.e. on its front).

[DCM] 0018 5100 CS        4     1710   PatientPosition                        [ HFP ]

@Chris_Rorden, any chance this could have had something to do with it
?

They were indeed on their front! I said supine in another post, which was a mistake on my part. I meant to say prone to help everyone understand the orientation but supine slipped out instead - my bad!

1 Like

@Scott, please see dcm2niix issue 238. This changes the warning and bvec rotation of dcm2niix when it encounters an image where Patient Position (0018,5100) is not Head First Supine. The new behavior mimics MRtrix and dicm2nii, and appears to work based on this limited example.

  1. At some stage, it would be great to get validation datasets that test the assumptions of all of our tools in these situations.
  2. As noted previously, the A>P and S>I directions appear to be swapped regardless of the converter you use (or indeed if you view the NIfTIs or the raw DICOMs). This is because 0010,2210 is not provided. According to the DICOM standard we assume the participant is BIPED “If Anatomical Orientation Type (0010,2210) is absent or has a value of BIPED”. If you provide validation datasets where the console has been set up to know this is a “QUADRUPED”, we should be able to update our tools to rectify the situation. With your current scans, the issue reflects an operator error (quadruped was not specified) that impacted the DICOMs, not a problem with the DICOM to NIfTI conversion.

Just my 2 cents: I don’t think we need to handle this particularly, for the same reason that we don’t need to worry about handling different patient positionings. According to the standard:

If Anatomical Orientation Type (0010,2210) has a value of QUADRUPED, the

  • x-axis is increasing to the left (as opposed to right) side of the patient

  • the y-axis is increasing towards

    • the dorsal (as opposed to ventral) side of the patient for the neck, trunk and tail,
    • the dorsal (as opposed to ventral) side of the patient for the head,
    • the dorsal (as opposed to plantar or palmar) side of the distal limbs,
    • the cranial (as opposed caudal) side of the proximal limbs, and
  • the z-axis is increasing towards

    • the cranial (as opposed to caudal) end of the patient for the neck, trunk and tail,
    • the rostral (as opposed to caudal) end of the patient for the head, and
    • the proximal (as opposed to distal) end of the limbs

In other words, this setting sets up the PCS differently – and most importantly, appropriately. I reckon this means the right way to handle this is to do nothing at all


Doing nothing to the bvecs here does seem like the best course of action. No assumptions are made except that the operator set things up correctly at the console. If this was not the case (as in my example) we will observe that the anatomy doesn’t correspond to the labels assigned by the display software and if desired reorient both anatomy and bvecs (hopefully) in a coherent way.

I will try to provide such a validation set by April 2019.

Again, thanks for your help everyone!

Hi @mblesac

I’ve noticed that you’ve got a mosaic slice timing error. I am getting the same error when I use mrinfo on my DICOM images. This may be preventing me from getting my slice times.

Have you found a work around to get the slice times?

Cheers,
Thapa

This issue was addressed and merged to master back in November. Is your installation up to date? It should be a simple matter of git pull && ./build
 If it still doesn’t work then, let us know, we’ll need to look into it further.

Hi @jdtournier

Thank you for your reply.

I am using mrtrix/3.0_rc3, and using the mrinfo command to get STC data. However, I keep getting the error mentioned in my post earlier.

Cheers,
Thapa

The fix I referred to was merged quite some time after 3.0_RC3 was released. If you’re on 3.0_RC3 exactly, then it won’t include this fix. What does mrconvert --version report?

Hi @jdtournier

Thanks for clearing that out. I will give the “git pull && ./build
” a go.

Here is the what the mrconvert --version reports:

"== mrconvert unknown ==

64 bit release version, built Aug 15 2018, using Eigen 3.2.92
Author(s): J-Donald Tournier (jdtournier @ gmail. com) and Robert E. Smith (robert.smith@florey.edu.au)
Copyright © 2008-2018 the MRtrix3 contributors.

This Source Code Form is subject to the terms of the Mozilla Public License, v. 2.0. If a cop of the MPL was not distributed with this file, you can obtain on at http:// mozilla. org/MPL/2.0/

MRtrix3 is distrubuted in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

For more details, see http: // www. mrtrix. org./"

Ok, it looks like you’ve built MRtrix3 from a downloaded compressed file, rather than a git clone (that would explain the unknown version). The git pull will fail


I suggest you either start again using git as suggested in the instructions, or if that’s not possible, grab the latest download from GitHub (not the release version, grab the latest version of master – this link should do the trick)

Thank you. I will give it a go, and keep you posted. :slight_smile:

I wanted to follow up on this old post to say that I tried to acquire a QUADRUPED validation set but unfortunately this is not an option on our scanner (Siemens 3T Magnetom Verio). At present we are not able to specify Quadruped. This seems like a good reason to do nothing to the bvecs when converting from DICOM to NIFTI.