 |
 |
> We have acquired 6 slices of ASL images and wish to normalize. We > coregister these and a structural scan to a whole brain EPI acquired at > the same sitting. 2 questions, > 1) What is the better way to proceed, i) normalize the coregistered > structural to the T1 template and apply _sn.mat to the coregisterd > functional scans or ii) normalize the EPI and apply _sn.mat to > coregistered functional scans, or is there no difference? There is likely to be a difference - but the better option may be difficult to predict. One of the main factors relates to how much distortion you have in your EPI data. If it is very distorted, then a good registration with the structural scan may not be possible - in which case any spatial normalisation parameters derived from the structural won't be especially accurate when applied to the EPI. Other factors are the contrast and artifacts in your data. Because spatial normalisation relies on minimising the mean squared difference between an image and template, then the contrast in the data should be similar for optimal results. > 2) if / when normalizing the coregistered structural do we select the r* > image or the original structural, - in light of previous posting [Re: > normalization of few slices,Mon, 4 Dec 2000 15:26:50 +0000 (you don't > need to use the r* image created by coregistration, as the > coregistration transformation is added to the structural MRI .mat file)]? Select the original image (where the relative orientation is encoded by the .mat file). If you try the Check Reg button with the original data after coregistration, then you should see that these are also in register. This is done via the .mat files, rather than by reslicing the data themselves. The reason for chosing the original image is that resliced images sometimes contain regions where there is no data in the original image. These are assigned a value of zero, which the spatial normalisation would try to distort because there would be no corresponding zero regions in the template image. Best regards, -John