[Mrtrix-discussion] Question about the gradient direction table used in Mrtrix

Sat Jul 9 01:11:34 PDT 2016

Hi Ilaria,

Importing Bruker data correctly is unfortunately not trivial. My (limited)
experience with their DICOM data is that it's not consistent, so I wouldn't
recommend using it. But their 2dseq format is also difficult to handle
well, since the information is stored in a non-obvious format, which
furthermore changes from version to version. For this reason, there's
remarkably few packages out there that support it - and some have even
decided to remove support for it because of these issues.

So David is right that MRtrix3 does provide this script, which I'd included
as a quick fix to handle some of the data we were processing. But it is
provided on a 'best effort' basis, in case others find it useful. On that
note, I'm open to any improvements that others might come up with; David:
feel free to contact me if you think your changes could/should be included
in the MRtrix3 version.

So with that caveat, to answer as few of your questions:

> 1) I'm currently using mrtrix 0.2.12, do you think the scrip would apply
to that version as well?

It should, I think. All it does is read the Bruker headers and produce a
MRtrix3 text header, without touching the actual data. This can then be
converted to NIFTI or used directly in any version of MRtrix.

> 2) I'm getting dicom from the Bruker scanner. I convert them into .nii
and then in .mif files, which I use for tracking.
>
> Can use the script to convert from nifti to mif?

No. It's exclusively for conversion from 2dseq to mih (not mif - see
http://mrtrix.readthedocs.io/en/latest/getting_started/image_data.html#mrtrix-image-formats-mih-mif
for a description of the two very formats).

> 3) the script is not commented + I'm not familiar with python. I have
difficulties in understanding in details what the script is doing.

Yes, unfortunately given the issues surrounding Bruker format, it was not
something that I felt we should support officially, so I've not put any
effort into documenting it. That said, it's fairly standard python, so if
you're familiar with python, it should be relatively simple to figure out.

> I understand that:
>
> a) it is first loading the file (import sys, os.path), but I don't
understand how files/dir are organized.

No, the import directive in python simply means that we are using
functionality provided by the sys and os.path modules (which are very
standard python modules).

> b) it checks if the input provided is correct
>
> c) it extract relevant information from the input file and assigns
variables
>
> d) it rewrites the variables

Yes, that's pretty much it.

> Basically I don't understand in what way each variable changes.
>
>
> What I understood so far from analyzing my data is that the gradients
need to be reoriented. Specifically it seems that a YZ swap is doing the
best job, but I'm not sure this is correct/optimal.
>
>
> Is the script doing something like this swap? Could you point the lines
where this happens?

The last few lines in the script write the DW information, and you can see
that the variables used to hold that information in the script are bvec and
bval. They're not modified in any way from what was in the 2dseq headers
when read in, but the z axis is inverted in the final "f.write()" call.
They may indeed need further modification.

> It would be very helpful to run the script line-by-line and see
what happens to the variable, but I don't have the right input file,
nor I work in python.

All you need to do is modify the final "f.write ('dw_scheme: ' ..." line as
you see fit.

> I guess the script can be converted in a bash script, right?

Not without a lot of effort. This is something python can handle a lot more
cleanly than bash, I'd expect any effort to convert that to bash would lead
to a very cumbersome and ultimately more obscure script...

In terms of verifying the validity of the reconstruction, I don't recommend
looking at the final tractography, it's not necessarily the most helpful
thing to do. But then anything you do will require a good understanding of
the anatomy you're looking at, so you can check that the orientations
estimated by the DW processing actually match expectation. It's not trivial
to figure out what needs to be done with these gradients - see for example
this recent conversation on the MRtrix3 forum:
http://community.mrtrix.org/t/instructions-for-response-function/269/21 -
there's lots of other examples in there if you look through that forum.

Hope this helps.
Cheers,
Donald

>
> Thanks a lot,
>
> Ilaria
>
>
>
>
>
> -------------------------------------------
> Ilaria Sani, PhD
> Postdoctoral Fellow, Freiwald Lab
> The Rockefeller University
> 1230 York Ave., New York, NY 10065.
> Phone: (212) 327 7699
> Fax:     (212) 327 7698
> Email: isani01 at rockefeller.edu
> ________________________________
> From: David Wright <wrightd at unimelb.edu.au>
> Sent: Thursday, July 7, 2016 7:47 PM
> To: Ilaria Sani; mrtrix-discussion at www.nitrc.org
> Subject: RE: [Mrtrix-discussion] Question about the gradient direction
table used in Mrtrix
>
> Hi Ilaria,
>
> There is a really handy script within MRtrix3 called convert_bruker which
you can use to convert a Bruker 2dseq file into a .mih file for use with
MRtrix. However, I've found that this script can occasionally reconstruct
the data incorrectly and so I've made a couple of modifications to get it
working for our data. Its still very much a work in progress, but you're
welcome to download it and give it a try:
>
> https://cloudstor.aarnet.edu.au/plus/index.php/s/bHhr1HXDo9T1cdE
>
> Let me know if you run into any problems.
>
> Cheers
>
> David
>
> ________________________________
> From: mrtrix-discussion-bounces at www.nitrc.org [
mrtrix-discussion-bounces at www.nitrc.org] on behalf of Ilaria Sani [
isani01 at mail.rockefeller.edu]
> Sent: Friday, 8 July 2016 12:45 AM
> To: mrtrix-discussion at www.nitrc.org
> Subject: [Mrtrix-discussion] Question about the gradient direction table
used in Mrtrix
>
> Dear All,
>
>
> I found the helpful post below from 2003, but I need some extra help.
>
>
> I'm analyzing ex-vivo data acquired with a 7T bruker scanner.
>
> This means that both "patient coordinate system" and the "scanner
coordinate system" are peculiar.
>
>
> The brain is positioned as if the patient was lying in sphynx position.
It means that left and right are inverted and that coronal and sagittal are
inverted.
>
>
> As for the scanner, I don't know how the bruker scanner compare to the
trio or GE...
>
> So I've been trying to invert and swap the gradient table.
>
> There are some combinations of swap/invert that return a higher number of
fibers when I perform ROI-to-ROI tracking. However,
>
> - I still see discrepancies, for example in the two hemispheres. The
number of selected fibers can vary 1-2 order magnitude. Especially with
small ROIs.
>
> - the RGB color cording is not correct, i.e. the color of vertical and
horizontal fibers is inverted.
>
>
>
> I tried to replicate the swap/invert procedures in other software to
double check whether I was doing things right, but I got different results.
So I guess the gradient table convention is specific to MRTRIX.
>
>
> Can anybody help me to understand if I'm doing things right?
>
>
> Thanks!!
>
> Ilaria
>
>
>
> -------------------------------------------
> Ilaria Sani, PhD
> Postdoctoral Fellow, Freiwald Lab
> The Rockefeller University
> 1230 York Ave., New York, NY 10065.
> Phone: (212) 327 7699
> Fax:     (212) 327 7698
> Email: isani01 at rockefeller.edu
>
>
>
>
> Donald Tournier d.tournier at brain.org.au
> Tue Apr 2 20:26:11 PDT 2013
> Previous message: [Mrtrix-discussion] Question about the gradient
direction table used in Mrtrix
> Next message: [Mrtrix-discussion] Question about the gradient direction
table used in Mrtrix
> Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> ________________________________
>
> Hi Sangma,
>
> OK, there's quite a few issues at play here. First off, the convention
used
> in MRtrix is that the gradients are specified with respect to the DICOM
> patient coordinate system. This is essentially the same convention as for
> DICOM images produced on Siemens and Philips scanners, and the newer
> standard DICOM tags recently introduced, with one notable exception: the
> DICOM patient-centered coordinate system has its x-axis running
> right-to-left and its y-axis running anterior-posterior, whereas MRtrix
> assumes these axes run in the opposite direction (as per the NIfTI
> standard). So MRtrix will flip the x & y components to account for this.
>
> For Siemens & Philips images, that's essentially all that happens to the
DW
> gradients. For GE images, it's a little different, since in this case the
> gradients are (or at least, used to be) stored with respect to the images
> axes. This means that to convert to MRtrix convention, they must be
> re-oriented back into the patient-centered coordinate system. This is what
> the rotate_DW_scheme flag specifies: when the DW gradient information was
> read from a GE-specific tag, this is set to true and the gradients are
then
> rotated according to the direction of the images axes. In this case, the z
> component is inverted, since flipping the x & y is essentially the same as
> flipping z, given the symmetry of diffusion.
>
> As far as I know, dcm2nii provides the DW directions with respect to the
> image axes (in the NIfTI coordinate system). To convert these back to
> MRtrix convention, the same transformation as you highlighted is needed,
> but *without* the negative sign. The transform you highlighted also
> accounts for differences in the directions of these axes due to the
> different conventions used for DICOM versus NifTI/MRtrix, so is not
> appropriate as-is to do convert a dcm2nii-supplied gradient table into one
> suitable for MRtrix. This is because the dcm2nii gradient table is
provided
> with respect to the image axes in NIfTI coordinate space, and in MRtrix
> they are provided with respect to the original axes, also in NIfTI
> coordinate space.
>
> To get back to your question, what do you mean when you say 'the original
> gradient table'? The one supplied by dcm2nii (in which case converting
> using the highlighted section of code would not work, as explained above),
> or the actual ones as read directly from the DICOM headers? If the latter,
> then unless your images were acquired on a GE scanner, then that also
would
> not work, since that section of code would only be used for GE images. If
> you are trying to convert non-GE DW directions read directly from the
DICOM
> headers, then all you need to do is flip the sign of the x & y components.
>
> Basically, it's really hard to keep track of all the possible conventions
> and what each step in the processing pipeline might have done to the DW
> gradients. Hopefully the above will help you figure out where the problem
> might be...
>
> Hope this helps.
> Cheers,
>
> Donald.
>
>
> On 3 April 2013 12:57, smxie_nlpr <smxie at nlpr.ia.ac.cn> wrote:
>
> > **
> >  Hi,
> >
> > I have a question about the gradient direction table used in Mrtrix. The
> > gradient direction table achieved from the DICOM images with dcm2nii is
> > different from the table achieved with the command 'mrinfo DICOMDIR
-grad
> > encoding.b'. I checked the source code of Mrtrix and found the following
> > codes '
> > if(rotate_DW_scheme)
> >  {
> > G(n,0) = image_transform(0,0) * d[0] + image_transform(0,1) * d[1] -
> > image_transform(0,2) * d[2];
> > G(n,1) = image_transform(1,0) * d[0] + image_transform(1,1) * d[1] -
> > image_transform(1,2) * d[2];
> > G(n,2) = image_transform(2,0) * d[0] + image_transform(2,1) * d[1] -
> > image_transform(2,2) * d[2];
> > }' in image.cpp.
> > I transformed the original gradient table with similar code in Matlab,
but
> > the result is not equal to the table achieved with mrinfo. So I want to
> > know the procedure of transforming the original gradients to the
gradients
> > achieved with mrinfo. And why is it 'G(n,0) = image_transform(0,0) *
d[0]
> > + image_transform(0,1) * d[1] - image_transform(0,2) * d[2];' rather
than
> > 'G(n,0) = image_transform(0,0) * d[0] + image_transform(0,1) * d[1] +
> > image_transform(0,2) * d[2];' ?
> >
> > Thanks.
> >
> > Sangma Xie
> > ------------------------------
> >  Sangma Xie , Master
> > Brainnetome Center
> > National Laboratory of Pattern Recognition (NLPR)
> > Institute of Automation, Chinese Academy of Sciences (CASIA)
> > 95 Zhong Guan Cun East Road, Hai Dian District, Beijing 100190,
P.R.China
> >
>
>
>
> _______________________________________________
> Mrtrix-discussion mailing list
> Mrtrix-discussion at www.nitrc.org
> http://www.nitrc.org/mailman/listinfo/mrtrix-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.nitrc.org/pipermail/mrtrix-discussion/attachments/20160709/6cbb726e/attachment-0001.html>