[Mristudio-users] 2 questions

[susumu mori]

These two are similar.
The orders of the images stored in the REC and DICOM are not the same. The
b0 is stored second from the last in REC and it is stored first in DICOM.
If you remove the b0, the numbers are about the same.
I suspect the difference is due to oblique angle imaging.

The gradient table is very tricky. First I have to make a disclaimer. It is
very difficult to make a tool that works for every data set.
I already described in this email list about how you can do self-defense
about this issue by performing imaging with severe oblique angles.

Anyway, here are why it is so complicated;
1) there is the "original" gradient table.
2) when imaging plane is rotated during the scan, the gradient table may or
may not rotate with the image. If not, gradient [1, 0, 0] always means
"physical X gradient" no matter the values of oblique angles. If rotated,
gradient [1, 0, 0] means X coordinate of the image, which is the
combination of physical X, Y, Z gradients.

Siemens usually use the former.
Philips and GE usually do the latter.
If you choose Philips "gradient overplus" option, it uses the former option.

If the gradient table stays with the physical X, Y, Z gradient coordinates
(former), gradient table has to be recalculated in the image coordinates.
For example, [1, 0, 0] means the pure X gradient and when you look at an
image recorded with oblique angles, you don't know what is the angle of
X-gradient anymore. That means, [1, 0, 0] has to be recalculated based on
the image oblique angles. In the image coordinates, the X-gradient could be
something like [0.9, 0.1, 0.09].
If the scanner does later, you can use the [1, 0, 0] as is for tensor
calculation.

3) you have to be careful when you read gradient information stored in the
image files. In addition to the former/latter freedom in #2, there is a
freedom to save the gradient information in physical or image coordinates.
For example, suppose your scanner did the latter option. Your gradient
table says [1, 0, 0] and your image plane was tilted. Because your gradient
table was rotated with the image, the actual gradient in physical
coordinates could be [0.9, 0.14, 0] (combination of X and Y gradient) but
stays as [1, 0, 0] in the image coordinate.
Now, when you open up the gradient table in an image file, it may be
recorded as [0.9, 0.14, 0]. In this case, you have to rotate this based on
the oblique angle and you should get [1, 0, 0]. If the image file stores
the gradient in the image coordinates, you should find [1, 0, 0] in the
file and you can use it as is.

Now, it seems that your gradient table is Philips Overplus. That means the
scanner did the "former" type.
In DICOM, "usually (not guaranteed)", the gradient table in the physical
gradient coordinates are recorded (it records what each gradient did).
This explains why the gradient table in DICOM looks cleaner (same values
everywhere), because it should be always the same regardless of oblique
angles. You can check it by looking at different DICOM files.

The MatLab code provided by JHU was developed by another group and I don't
know exactly how it works, but I assume that it reads the gradient table
and already rotated the gradient based on the oblique angle.

If you are using enhanced DICOM files, you can use DtiStudio's "extract
gradient' function. Because you used Overplus, the table has to be rotated
by clicking "rotate if applicable" check box. You can load the data and
close the window, and reopen the initial data input window. There it
remembers the previous recalculated table. If this table seems the same as
the one from the MatLab code, then problem solved.

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