<div dir="ltr">These two are similar.<div style>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.</div><div style>If you remove the b0, the numbers are about the same.</div>
<div style>I suspect the difference is due to oblique angle imaging.</div><div style><br></div><div style>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.</div>
<div style>I already described in this email list about how you can do self-defense about this issue by performing imaging with severe oblique angles.</div><div style><br></div><div style>Anyway, here are why it is so complicated;</div>
<div style>1) there is the "original" gradient table.</div><div style>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.</div>
<div style><br></div><div style>Siemens usually use the former.</div><div style>Philips and GE usually do the latter.</div><div style>If you choose Philips "gradient overplus" option, it uses the former option.</div>
<div style><br></div><div style>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]. </div>
<div style>If the scanner does later, you can use the [1, 0, 0] as is for tensor calculation.</div><div style><br></div><div style>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. </div>
<div style>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.</div>
<div style>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. </div>
<div style><br></div><div style>Now, it seems that your gradient table is Philips Overplus. That means the scanner did the "former" type.</div><div style>In DICOM, "usually (not guaranteed)", the gradient table in the physical gradient coordinates are recorded (it records what each gradient did).</div>
<div style>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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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. </div>
</div>