[Mrtrix-discussion] Question about the gradient direction table used in Mrtrix
J-Donald Tournier
jdtournier at gmail.com
Mon Jul 25 02:45:32 PDT 2016
Hi Ilaria,
Sorry about the late response - trying to juggle too many things yet
again...
To answer your questions:
> I was able to get the 2dseq and convert it into a mih file.
>
> As Donald predicted the mih file is different from the mif header
obtained from dicoms (see below).
>
> And actually none of them match my expectations.
Yes, I'm not too surprised. For the 2dseq import, and having discussed a
bit further with David, there's quite a few issues to sort out before we
can get this right every time. Right now, it's fair to say that the outcome
with depend on your acquisition parameters (and probably software version
too).
> I empirically tried to swap/invert gradients. Based on the fiber anatomy
and the number of fibers obtained I concluded that a YZ swap would be the
best option.... however none of the Data Layout from the header would
predict such swap.
>
> Do you agree?
The Data Layout is unlikely to be related, at least given how the script
works currently. As far as I know, the information read from the headers
currently uses a field that provides the gradient directions with respect
to the scanner coordinate system, so should be independent of the layout.
David's modifications actually change this to read the gradients with
respect to the image phase/read/slice coordinate system, in which case the
data layout does matter...
> Let me ask just one more question. As a double check I tried to get
fibers using another software (Trackvis). In that case a YZswap and a
Zinversion would produce the best results. Do think this make sense? In
other words, do different software need different grads reorientation?
Yes, I'd anticipate that would be the case. MRtrix expects the gradients in
the scanner coordinate system, whereas most other package would expect it
relative to the image (i.e. bvec/bvals format). So the discrepancies would
manifest differently depending on the image acquisition axes, etc.
Hopefully this will improve in due course, as we figure things out. David
had kindly agreed to look into this and verify the import against different
scan parameters, which will provide some essential sanity checking if this
script is to become more widely used...
Cheers,
Donald
> Thank you again,
>
> Ilaria
>
>
>
> ************************************************
> Image: "header.mih"
> ************************************************
> Format: MRtrix
> Dimensions: 320 x 320 x 256 x 61
> Voxel size: 0.25 x 0.25 x 0.253906 x 0.253906
> Dimension labels: 0. undefined (?)
> 1. undefined (?)
> 2. undefined (?)
> 3. undefined (?)
> Data type: signed 16 bit integer (little endian)
> Data layout: [ +0 +1 +2 +3 ]
> Data scaling: offset = 0, multiplier = 1
> Comments: (none)
> Transform: 1 0 0 1
> 0 1 0 1
> 0 0 1 1
> 0 0 0 1
> DW scheme: 61 x 4
>
>
>
>
> ************************************************
> Image: "dwi.mif"
> ************************************************
> Format: MRtrix
> Dimensions: 320 x 256 x 320 x 61
> Voxel size: 0.25 x 0.253906 x 0.25 x 0.5
> Dimension labels: 0. left->right (mm)
> 1. posterior->anterior (mm)
> 2. inferior->superior (mm)
> 3. undefined (?)
> Data type: signed 16 bit integer (little endian)
> Data layout: [ -0 -2 +1 +3 ]
> Data scaling: offset = 0, multiplier = 1
> Comments: TE=36.49499893;sec=28455.0000
> Transform: 1 -0 0 -39.75
> -0 1 0 -29.88
> -0 -0 1 -38.25
> 0 0 0 1
>
>
> -------------------------------------------
> 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: J-Donald Tournier <jdtournier at gmail.com>
> Sent: Saturday, July 9, 2016 4:11 AM
>
> To: Ilaria Sani
> Cc: Brent McPherson; David Wright; mrtrix-discussion at www.nitrc.org
> Subject: Re: [Mrtrix-discussion] Question about the gradient direction
table used in Mrtrix
>
>
> 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/20160725/a4f79774/attachment-0001.html>
More information about the Mrtrix-discussion
mailing list