<p dir="ltr">Hi Ilaria,</p>
<p dir="ltr">Sorry about the late response - trying to juggle too many things yet again...</p>
<p dir="ltr">To answer your questions:</p>
<p dir="ltr">> I was able to get the 2dseq and convert it into a mih file.<br>
><br>
> As Donald predicted the mih file is different from the mif header obtained from dicoms (see below).<br>
><br>
> And actually none of them match my expectations.</p>
<p dir="ltr">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).</p>
<p dir="ltr">> 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.<br>
><br>
> Do you agree?</p>
<p dir="ltr">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.</p>
<p dir="ltr">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...</p>
<p dir="ltr">> 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?</p>
<p dir="ltr">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. <br></p>
<p dir="ltr">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...<br></p>
<p dir="ltr">Cheers,<br>
Donald<br></p>
<p dir="ltr">> Thank you again,<br>
><br>
> Ilaria<br>
><br>
><br>
><br>
> ************************************************<br>
> Image: "header.mih"<br>
> ************************************************<br>
> Format: MRtrix<br>
> Dimensions: 320 x 320 x 256 x 61<br>
> Voxel size: 0.25 x 0.25 x 0.253906 x 0.253906<br>
> Dimension labels: 0. undefined (?)<br>
> 1. undefined (?)<br>
> 2. undefined (?)<br>
> 3. undefined (?)<br>
> Data type: signed 16 bit integer (little endian)<br>
> Data layout: [ +0 +1 +2 +3 ]<br>
> Data scaling: offset = 0, multiplier = 1<br>
> Comments: (none)<br>
> Transform: 1 0 0 1<br>
> 0 1 0 1<br>
> 0 0 1 1<br>
> 0 0 0 1<br>
> DW scheme: 61 x 4<br>
><br>
><br>
><br>
><br>
> ************************************************<br>
> Image: "dwi.mif"<br>
> ************************************************<br>
> Format: MRtrix<br>
> Dimensions: 320 x 256 x 320 x 61<br>
> Voxel size: 0.25 x 0.253906 x 0.25 x 0.5<br>
> Dimension labels: 0. left->right (mm)<br>
> 1. posterior->anterior (mm)<br>
> 2. inferior->superior (mm)<br>
> 3. undefined (?)<br>
> Data type: signed 16 bit integer (little endian)<br>
> Data layout: [ -0 -2 +1 +3 ]<br>
> Data scaling: offset = 0, multiplier = 1<br>
> Comments: TE=36.49499893;sec=28455.0000<br>
> Transform: 1 -0 0 -39.75<br>
> -0 1 0 -29.88<br>
> -0 -0 1 -38.25<br>
> 0 0 0 1<br>
><br>
><br>
> -------------------------------------------<br>
> Ilaria Sani, PhD<br>
> Postdoctoral Fellow, Freiwald Lab<br>
> The Rockefeller University<br>
> 1230 York Ave., New York, NY 10065.<br>
> Phone: (212) 327 7699<br>
> Fax: (212) 327 7698<br>
> Email:<a href="mailto:isani01@rockefeller.edu"> isani01@rockefeller.edu</a><br>
> ________________________________<br>
> From: J-Donald Tournier <<a href="mailto:jdtournier@gmail.com">jdtournier@gmail.com</a>><br>
> Sent: Saturday, July 9, 2016 4:11 AM<br>
><br>
> To: Ilaria Sani<br>
> Cc: Brent McPherson; David Wright;<a href="mailto:mrtrix-discussion@www.nitrc.org"> mrtrix-discussion@www.nitrc.org</a><br>
> Subject: Re: [Mrtrix-discussion] Question about the gradient direction table used in Mrtrix<br>
> <br>
><br>
> Hi Ilaria,<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> So with that caveat, to answer as few of your questions:<br>
><br>
> > 1) I'm currently using mrtrix 0.2.12, do you think the scrip would apply to that version as well?<br>
><br>
> 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.<br>
><br>
> > 2) I'm getting dicom from the Bruker scanner. I convert them into .nii and then in .mif files, which I use for tracking.<br>
> ><br>
> > Can use the script to convert from nifti to mif?<br>
><br>
> No. It's exclusively for conversion from 2dseq to mih (not mif - see<a href="http://mrtrix.readthedocs.io/en/latest/getting_started/image_data.html#mrtrix-image-formats-mih-mif"> http://mrtrix.readthedocs.io/en/latest/getting_started/image_data.html#mrtrix-image-formats-mih-mif</a> for a description of the two very formats).<br>
><br>
> > 3) the script is not commented + I'm not familiar with python. I have difficulties in understanding in details what the script is doing.<br>
><br>
> 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.<br>
><br>
> > I understand that:<br>
> ><br>
> > a) it is first loading the file (import sys, os.path), but I don't understand how files/dir are organized.<br>
><br>
> 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).<br>
><br>
> > b) it checks if the input provided is correct<br>
> ><br>
> > c) it extract relevant information from the input file and assigns variables<br>
> ><br>
> > d) it rewrites the variables<br>
><br>
> Yes, that's pretty much it.<br>
><br>
> > Basically I don't understand in what way each variable changes.<br>
> ><br>
> ><br>
> > 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.<br>
> ><br>
> ><br>
> > Is the script doing something like this swap? Could you point the lines where this happens?<br>
><br>
> 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.<br>
><br>
> > 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.<br>
><br>
> All you need to do is modify the final "f.write ('dw_scheme: ' ..." line as you see fit.<br>
><br>
> > I guess the script can be converted in a bash script, right?<br>
><br>
> 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...<br>
><br>
> 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:<a href="http://community.mrtrix.org/t/instructions-for-response-function/269/21"> http://community.mrtrix.org/t/instructions-for-response-function/269/21</a> - there's lots of other examples in there if you look through that forum.<br>
><br>
> Hope this helps.<br>
> Cheers,<br>
> Donald<br>
><br>
> ><br>
> > Thanks a lot,<br>
> ><br>
> > Ilaria <br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > -------------------------------------------<br>
> > Ilaria Sani, PhD<br>
> > Postdoctoral Fellow, Freiwald Lab<br>
> > The Rockefeller University<br>
> > 1230 York Ave., New York, NY 10065.<br>
> > Phone: (212) 327 7699<br>
> > Fax: (212) 327 7698<br>
> > Email:<a href="mailto:isani01@rockefeller.edu"> isani01@rockefeller.edu</a><br>
> > ________________________________<br>
> > From: David Wright <<a href="mailto:wrightd@unimelb.edu.au">wrightd@unimelb.edu.au</a>><br>
> > Sent: Thursday, July 7, 2016 7:47 PM<br>
> > To: Ilaria Sani;<a href="mailto:mrtrix-discussion@www.nitrc.org"> mrtrix-discussion@www.nitrc.org</a><br>
> > Subject: RE: [Mrtrix-discussion] Question about the gradient direction table used in Mrtrix<br>
> > <br>
> > Hi Ilaria,<br>
> ><br>
> > 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:<br>
> ><br>
> ><a href="https://cloudstor.aarnet.edu.au/plus/index.php/s/bHhr1HXDo9T1cdE"> https://cloudstor.aarnet.edu.au/plus/index.php/s/bHhr1HXDo9T1cdE</a><br>
> ><br>
> > Let me know if you run into any problems. <br>
> ><br>
> > Cheers<br>
> ><br>
> > David<br>
> ><br>
> > ________________________________<br>
> > From:<a href="mailto:mrtrix-discussion-bounces@www.nitrc.org"> mrtrix-discussion-bounces@www.nitrc.org</a> [<a href="mailto:mrtrix-discussion-bounces@www.nitrc.org">mrtrix-discussion-bounces@www.nitrc.org</a>] on behalf of Ilaria Sani [<a href="mailto:isani01@mail.rockefeller.edu">isani01@mail.rockefeller.edu</a>]<br>
> > Sent: Friday, 8 July 2016 12:45 AM<br>
> > To:<a href="mailto:mrtrix-discussion@www.nitrc.org"> mrtrix-discussion@www.nitrc.org</a><br>
> > Subject: [Mrtrix-discussion] Question about the gradient direction table used in Mrtrix<br>
> ><br>
> > Dear All,<br>
> ><br>
> ><br>
> > I found the helpful post below from 2003, but I need some extra help.<br>
> ><br>
> ><br>
> > I'm analyzing ex-vivo data acquired with a 7T bruker scanner.<br>
> ><br>
> > This means that both "patient coordinate system" and the "scanner coordinate system" are peculiar.<br>
> ><br>
> ><br>
> > 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.<br>
> ><br>
> ><br>
> > As for the scanner, I don't know how the bruker scanner compare to the trio or GE...<br>
> ><br>
> > So I've been trying to invert and swap the gradient table.<br>
> ><br>
> > There are some combinations of swap/invert that return a higher number of fibers when I perform ROI-to-ROI tracking. However,<br>
> ><br>
> > - 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.<br>
> ><br>
> > - the RGB color cording is not correct, i.e. the color of vertical and horizontal fibers is inverted.<br>
> ><br>
> > <br>
> ><br>
> > 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.<br>
> ><br>
> ><br>
> > Can anybody help me to understand if I'm doing things right?<br>
> ><br>
> ><br>
> > Thanks!!<br>
> ><br>
> > Ilaria<br>
> ><br>
> ><br>
> ><br>
> > -------------------------------------------<br>
> > Ilaria Sani, PhD<br>
> > Postdoctoral Fellow, Freiwald Lab<br>
> > The Rockefeller University<br>
> > 1230 York Ave., New York, NY 10065.<br>
> > Phone: (212) 327 7699<br>
> > Fax: (212) 327 7698<br>
> > Email:<a href="mailto:isani01@rockefeller.edu"> isani01@rockefeller.edu</a><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > Donald Tournier d.tournier at<a href="http://brain.org.au"> brain.org.au</a> <br>
> > Tue Apr 2 20:26:11 PDT 2013<br>
> > Previous message: [Mrtrix-discussion] Question about the gradient direction table used in Mrtrix<br>
> > Next message: [Mrtrix-discussion] Question about the gradient direction table used in Mrtrix<br>
> > Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]<br>
> > ________________________________<br>
> ><br>
> > Hi Sangma,<br>
> ><br>
> > OK, there's quite a few issues at play here. First off, the convention used<br>
> > in MRtrix is that the gradients are specified with respect to the DICOM<br>
> > patient coordinate system. This is essentially the same convention as for<br>
> > DICOM images produced on Siemens and Philips scanners, and the newer<br>
> > standard DICOM tags recently introduced, with one notable exception: the<br>
> > DICOM patient-centered coordinate system has its x-axis running<br>
> > right-to-left and its y-axis running anterior-posterior, whereas MRtrix<br>
> > assumes these axes run in the opposite direction (as per the NIfTI<br>
> > standard). So MRtrix will flip the x & y components to account for this.<br>
> ><br>
> > For Siemens & Philips images, that's essentially all that happens to the DW<br>
> > gradients. For GE images, it's a little different, since in this case the<br>
> > gradients are (or at least, used to be) stored with respect to the images<br>
> > axes. This means that to convert to MRtrix convention, they must be<br>
> > re-oriented back into the patient-centered coordinate system. This is what<br>
> > the rotate_DW_scheme flag specifies: when the DW gradient information was<br>
> > read from a GE-specific tag, this is set to true and the gradients are then<br>
> > rotated according to the direction of the images axes. In this case, the z<br>
> > component is inverted, since flipping the x & y is essentially the same as<br>
> > flipping z, given the symmetry of diffusion.<br>
> ><br>
> > As far as I know, dcm2nii provides the DW directions with respect to the<br>
> > image axes (in the NIfTI coordinate system). To convert these back to<br>
> > MRtrix convention, the same transformation as you highlighted is needed,<br>
> > but *without* the negative sign. The transform you highlighted also<br>
> > accounts for differences in the directions of these axes due to the<br>
> > different conventions used for DICOM versus NifTI/MRtrix, so is not<br>
> > appropriate as-is to do convert a dcm2nii-supplied gradient table into one<br>
> > suitable for MRtrix. This is because the dcm2nii gradient table is provided<br>
> > with respect to the image axes in NIfTI coordinate space, and in MRtrix<br>
> > they are provided with respect to the original axes, also in NIfTI<br>
> > coordinate space.<br>
> ><br>
> > To get back to your question, what do you mean when you say 'the original<br>
> > gradient table'? The one supplied by dcm2nii (in which case converting<br>
> > using the highlighted section of code would not work, as explained above),<br>
> > or the actual ones as read directly from the DICOM headers? If the latter,<br>
> > then unless your images were acquired on a GE scanner, then that also would<br>
> > not work, since that section of code would only be used for GE images. If<br>
> > you are trying to convert non-GE DW directions read directly from the DICOM<br>
> > headers, then all you need to do is flip the sign of the x & y components.<br>
> ><br>
> > Basically, it's really hard to keep track of all the possible conventions<br>
> > and what each step in the processing pipeline might have done to the DW<br>
> > gradients. Hopefully the above will help you figure out where the problem<br>
> > might be...<br>
> ><br>
> > Hope this helps.<br>
> > Cheers,<br>
> ><br>
> > Donald.<br>
> ><br>
> ><br>
> > On 3 April 2013 12:57, smxie_nlpr <smxie at<a href="http://nlpr.ia.ac.cn"> nlpr.ia.ac.cn</a>> wrote:<br>
> ><br>
> > > **<br>
> > > Hi,<br>
> > ><br>
> > > I have a question about the gradient direction table used in Mrtrix. The<br>
> > > gradient direction table achieved from the DICOM images with dcm2nii is<br>
> > > different from the table achieved with the command 'mrinfo DICOMDIR -grad<br>
> > > encoding.b'. I checked the source code of Mrtrix and found the following<br>
> > > codes '<br>
> > > if(rotate_DW_scheme)<br>
> > > {<br>
> > > G(n,0) = image_transform(0,0) * d[0] + image_transform(0,1) * d[1] -<br>
> > > image_transform(0,2) * d[2];<br>
> > > G(n,1) = image_transform(1,0) * d[0] + image_transform(1,1) * d[1] -<br>
> > > image_transform(1,2) * d[2];<br>
> > > G(n,2) = image_transform(2,0) * d[0] + image_transform(2,1) * d[1] -<br>
> > > image_transform(2,2) * d[2];<br>
> > > }' in image.cpp.<br>
> > > I transformed the original gradient table with similar code in Matlab, but<br>
> > > the result is not equal to the table achieved with mrinfo. So I want to<br>
> > > know the procedure of transforming the original gradients to the gradients<br>
> > > achieved with mrinfo. And why is it 'G(n,0) = image_transform(0,0) * d[0]<br>
> > > + image_transform(0,1) * d[1] - image_transform(0,2) * d[2];' rather than<br>
> > > 'G(n,0) = image_transform(0,0) * d[0] + image_transform(0,1) * d[1] +<br>
> > > image_transform(0,2) * d[2];' ?<br>
> > ><br>
> > > Thanks.<br>
> > ><br>
> > > Sangma Xie<br>
> > > ------------------------------<br>
> > > Sangma Xie , Master<br>
> > > Brainnetome Center<br>
> > > National Laboratory of Pattern Recognition (NLPR)<br>
> > > Institute of Automation, Chinese Academy of Sciences (CASIA)<br>
> > > 95 Zhong Guan Cun East Road, Hai Dian District, Beijing 100190, P.R.China<br>
> > ><br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > Mrtrix-discussion mailing list<br>
> ><a href="mailto:Mrtrix-discussion@www.nitrc.org"> Mrtrix-discussion@www.nitrc.org</a><br>
> ><a href="http://www.nitrc.org/mailman/listinfo/mrtrix-discussion"> http://www.nitrc.org/mailman/listinfo/mrtrix-discussion</a><br>
> ></p>