[Mristudio-users] mristudio-users Digest, Vol 54, Issue 2

Thu Dec 30 18:20:46 EST 2010

You are welcome,

Yes, they are rotation invariant indices since they are all tensor-based. 

You just image one ellipsoid in the 3D space, all you diffusion measures are
used to determine the shape of the tensor, now you rotate the gradient
table, which cause the ellipsoid to rotate in 3D space, but the shape (or in
other words, 3D profile of the tensor) won't change unless you change your
measurement

Liang

.

From: mristudio-users-bounces at mristudio.org
[mailto:mristudio-users-bounces at mristudio.org] On Behalf Of Jeff Sadino
Sent: Thursday, December 30, 2010 3:04 PM
To: DTI Studio, ROI Editor, DiffeoMap Questions/Support
Subject: Re: [Mristudio-users] mristudio-users Digest, Vol 54, Issue 2

Thank you Liang for clarifying that.  We are also looking at the
eigenvalues, ADC, and Trace.  Are those values also rotation invariant?
Those values also were changed by only about 0.2%.

Thank you,

Jeff

On Thu, Dec 30, 2010 at 12:52 PM, susumu mori <susumu at mri.jhu.edu> wrote:

Thanks Darren for detailed report. 

--- In the unrotated case the gradient directions reported by
DTIstudio were flipped in y and z vs. the default Siemens gradients.
Once the gradients reported by DTIstudio were multiplied by [1 -1 -1]
they were within 0.53 degrees of the default Siemens gradients.

Q1. > Is this flipping to be expected?

Yes. First of all, by saying "default Siemens gradient", I assume that you
mean the generic gradient table provided by Siemens. When we do head-first,
face-up, axial scan with AP phase-encode, we usually need to flip the sign
of X components, which is the same as [1, -1, -1] (=[-1, 1, 1]).

Q2. > If it is expected, isn't this a problem, because had I entered
my default Siemens gradient directions instead of extracting from
Dicom then the y and z directions would have been incorrect?

Yes, it is a problem. Philips users usually have to flip Z components. We
all have to figure it out and know it. It won't affect FA/ADC, but it
affects fiber tracking. Also, it has to be corrected before any
normalization process. We have to use a corrected table. Or,
DtiStudio/MriStudio offers "flip x/y/z" functions right before fiber
tracking or image transformation as the final line of defense.

--- Since no angulation was applied to the gradients the results from
DTIstudio did not change whether or not I clicked "Rotate gradients if
applicable". This is as expected.

--- In the rotated case the gradients are again flipped in the y and z
directions. However, the results are not the same as multiplying the
gradient values by the rotation matrix (It appears this process is
more complex than I expected, but after working through it in nibabel:
see- http://mail.scipy.org/pipermail/nipy-devel/2010-September/004768.html,
I agree that DTIstudio is probably rotating the gradients correctly.
The last thing I noticed, however, is that the results are again the
same whether or not I click rotate gradients if applicable.

I have several questions;

> Did you check the table after rotation by closing the window and restart
the initial data input window? If you did oblique imaging and check "rotate
if applicable", you should find the rotated table there.

> If you feed the generic Siemens table (which has wrong signs for the X
components), the rotated table remains incorrect in terms of the X component
signs. Is this what you mean?

> If you extract the gradient table from DICOM headers, then the initial
table fed to DtiStudio should have correct signs for all X/Y/Z components.
After rotation, it should remain correct. Did you try this?

> Now, I'm very interested in how the DICOM-extracted table looks like with
the oblique protocol. Is it similar to the generic table (except for the
sign difference) or similar to the one after the rotation? My past
experience says it is similar to the pre-rotation table and thus it still
has to be rotated ("rotate if applicable" needs to be clicked). Do you
agree?

Q3. > It appears that for Siemens data (VB17) the gradient rotation is
applied whether or not one clicks rotate gradients if applicable. Is
this correct?

I have to confirm with Hangyi, but I believe that gradient rotation is not
activated unless you click the check box. 

Hangyi, is this correct?

Thanks,
Darren

>
> ---------- Forwarded message ----------
> From: susumu mori <susumu at mri.jhu.edu>
> To: "DTI Studio, ROI Editor, DiffeoMap Questions/Support"
<mristudio-users at mristudio.org>
> Date: Mon, 27 Dec 2010 20:32:31 -0500
> Subject: Re: [Mristudio-users] gradient directions
> Hi Darren and Jeff,
> What Jeff said is correct. DtiStudio provides some handy functions such as
extracting gradient information from DICOM/Mosaic and apply rotation based
on the oblique angles. However, these functions are activated by users and
it is users who have to find out what is the correct way to get a gradient
table.
> As I mentioned before, for self-defense, I recommend to perform a couple
of imaging with severe oblique angles. For us, it is difficult to comment
differences with third party programs (we don't have experience with them),
but following are some important points to know;
> 1) The generic gradient tables provided by manufacturers may need to be
modified for x/y/z permutation and +/- definition.
> 2) The gradient table extracted from DICOM files may be used as is, but
that may not be the case for old DICOM formats.
> 3) We should be always careful when we use oblique angles.
> 4) The gradient table extracted from Siemens DICOM  (Mosaic) could be
different from the generic table because it contains a small amount of
contributions from imaging gradient.
> 5) As Jeff mentioned, to see the effect of the table recalculation based
on the oblique-angles, you need to close the window and reopen the initial
data input window. There, it remembers the results of the previous gradient
table calculation.
> Our past experience says that the generic Siemens gradient table and the
one extracted from  Mosaic are very close. The difference is usually within
+/- definition and the small image gradient contribution. The table remains
unchanged regardless of oblique angles (within the difference due to small
image gradient contribution).
> Please don't hesitate to further discuss this issue because there could be
something we are missing.
> On Mon, Dec 27, 2010 at 5:44 PM, Jeff Sadino <jsadino.queens at gmail.com>
wrote:
>>
>> Hi Darren,
>> I also spent some time on this recently on our Siemens VB17 software.
DTIStudio does not rotate the gradients until after you click "OK" to
visualize your images.  So regardless of whether or not you select "rotate
gradients if applicable", the gradient table that you will see DTIStudio
pull will be identical.  To see the modified table, visualize your data,
then close that window, then when you load up your next subject, you will
see the rotated table.
>> As far as I can tell, DTIStudio pulls whatever is written in the DICOM
header, without any modifications, unless you tell it to.
>> In the DICOM header, there is a tag called ImageOrientationPatient.
DTIStudio uses this tag to "know" whether or not a rotation is necessary.
>> I'm not sure about those specific third party programs, but I think some
of them flip the y direction so that they are more compatible with FSL
>> Hope it helps,
>> Jeff
>>
>> On Sun, Dec 26, 2010 at 3:18 PM, Darren Gitelman
<d-gitelman at northwestern.edu> wrote:
>>>
>>> Hi
>>>
>>> I know the issue of gradient directions has been brought up many
>>> times, but I am struggling with what the correct gradient directions
>>> should be. It's not that I doubt dtistudio, but I am puzzled by why
>>> the gradients end up different depending on how one converts the dicom
>>> data. I have spent some time plotting the gradient directions on a
>>> unit sphere and this is what i found (see below). I also have some
>>> questions about how dtistudio "knows" whether or not to rotate the
>>> gradients.
>>>
>>> I am using Siemens data acquired on a scanner with b17 software.
>>>
>>> If I click "get gradient from dicom file header" the values entered by
>>> DTIstudio don't seem to change whether or not I also click rotate
>>> gradients if applicable.
>>>
>>> Is DTIstudio automatically rotating the gradients when it gets them
>>> from the Siemens header?
>>>
>>> Clearly these gradients are different than if I pasted in the default
>>> Siemens gradients. How does DTIstudio know whether or not the
>>> gradients need rotating when I click the OK button? Here is what I
>>> mean- let's say I get the gradients from the Dicom image and I save
>>> these in a text file. Now I try 2 different ways of importing the DTI
>>> data: 1) in one case I paste the default Siemens gradients and in the
>>> other 2) I paste the gradients I obtained from the Dicom image. If I
>>> click rotate gradients if applicable, will DTIstudio know to rotate
>>> the gradients in case 1 (default Siemens directions) but not in case 2
>>> (acquired from Dicom file)?
>>>
>>> Is there any way to get the final gradients that DTIstudio is applying
>>> to the data?
>>>
>>> The whole process of obtaining the gradients seems to be somewhat of a
>>> mystery (to me anyway) and it's hard to know what is correct (at least
>>> for Siemens data). I also notice that the gradients obtained from the
>>> Dicom file are not the same as the gradients one obtains when
>>> converting the data via either dcm2nii
>>> (http://www.cabiatl.com/mricro/mricron/dcm2nii.html) or via mriconvert
>>> (http://lcni.uoregon.edu/~jolinda/MRIConvert/). The gradients from
>>> these conversions are flipped by -1 in the y direction from dtistudio.
>>> (In fact the gradients from mriconvert are nearly the same as
>>> dtistudio after accounting for this y-flip, while the gradients form
>>> dcm2nii are off by 4-6 degrees rotation after accounting for the
>>> y-flip).
>>>
>>> Any advice about the gradient directions and how to be sure what is
>>> correct would be appreciated.
>>>
>>> Thanks,
>>> Darren
>>> --
>>> Darren Gitelman, MD
>>> 710 N. Lake Shore Dr., 1122
>>> Chicago, IL 60611
>>> Ph: (312) 908-8614
>>> Fax: (312) 908-5073
>>> _______________________________________________
>>> mristudio-users mailing list
>>> mristudio-users at mristudio.org
>>> http://lists.mristudio.org/mailman/listinfo/
>>> Unsubscribe, send a blank email to:
mristudio-users-unsubscribe at mristudio.org
>>
>>
>> _______________________________________________
>> mristudio-users mailing list
>> mristudio-users at mristudio.org
>> http://lists.mristudio.org/mailman/listinfo/
>> Unsubscribe, send a blank email to:
mristudio-users-unsubscribe at mristudio.org
>>
>
>
>
> ---------- Forwarded message ----------
> From: HUA KEGANG <khua1 at jhu.edu>
> To: mristudio-users at mristudio.org
> Date: Tue, 28 Dec 2010 16:45:35 +0000
> Subject: Re: [Mristudio-users] update of gradient table in DtiStudio
> Hi, Luca
>
> The MI algorithm optimizes the normalized mutual information.
>
> Thanks!
>
> KEGANG(LUKE) HUA
> Department of Radiology
> Johns Hopkins University School of Medicine
> 720 Rutland Ave Traylor217
> Baltimore, MD, 21205
>
>
>
>
>> Date: Mon, 27 Dec 2010 09:38:00 +0100
>> From: luca.binotto at unipd.it
>> Subject: [Mristudio-users] update of gradient table in DtiStudio
>> To: mristudio-users at mristudio.org
>>
>> Hello Susumu,
>>
>> I would like to know something about the way DtiStudio performs the
update
>> of the gradient table after the realignment of the dti dataset with
>> respect to the mean_b0 volume.
>>
>> The registration algorithm implemented in DtiStudio using mutual
>> information (MI):
>> 1) does it uses normalized mutual information or which other formulation
?
>> 2) how is the gradient table updated ? (rough simple theory)
>> After realignment of the DWI volumes, b-matrix (the gradient table) must
>> be updated.
>>
>> Patient motion and eddy currents can cause errors in the calculation of
>> parameters that describe diffusion in each voxel of a DWI dataset.
>> In normal conditions eddy currents contribution should be
>> very small (< 1% ?).
>> But the b-matrix (gradient table) is calculated with respect to a fixed
>> coordinate system (at the acquisition time) so the b-matrix must be
>> rotated accordingly to the transformation applied for image registration
>> otherwise we should get poor fiber statistics and some fibers possibly
>> deviate.
>>
>> So the gradient table is affected by rotations. Translations don't
>> change it.
>> But what does it happen with resampling (applying a scaling factor: es.
>> affine transformation) to a dwi dataset?
>> According to you is normally its effect small (as for eddy currents
>> effect) or can be more important?
>> For example a scaling factor such that a volume with a voxel size of
>> 2x2x2 mm3 is resliced to a 1x1x1 mm3 voxel size can be important its
>> effect or "only" a lower image quality (eg. I read somewhere of a
>> "red background" superimposed to the correct color map)?
>>
>>
>> thanks in advance,
>> best regards,
>>
>> Luca
>>
>>
>>
>>
>> _______________________________________________
>> mristudio-users mailing list
>> mristudio-users at mristudio.org
>> http://lists.mristudio.org/mailman/listinfo/
>> Unsubscribe, send a blank email to:
mristudio-users-unsubscribe at mristudio.org
>
> _______________________________________________
> mristudio-users mailing list
> mristudio-users at mristudio.org
> http://lists.mristudio.org/mailman/listinfo/mristudio-users
>
>

--
Darren Gitelman, MD
710 N. Lake Shore Dr., 1122
Chicago, IL 60611
Ph: (312) 908-8614
Fax: (312) 908-5073

_______________________________________________
mristudio-users mailing list
mristudio-users at mristudio.org
http://lists.mristudio.org/mailman/listinfo/
Unsubscribe, send a blank email to:
mristudio-users-unsubscribe at mristudio.org

_______________________________________________
mristudio-users mailing list
mristudio-users at mristudio.org
http://lists.mristudio.org/mailman/listinfo/
Unsubscribe, send a blank email to:
mristudio-users-unsubscribe at mristudio.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mristudio.org/pipermail/mristudio-users/attachments/20101230/e5481645/attachment-0001.html 