 |
 |
Hi John, Thanks very much for your prompt email. I appreciate you explaining how SPM prefers qform transformations, and how transformations are written to the header files if SPM creates the image volume. However, your email does not explain the problem I am experiencing. I have attached the two .hdr files (one containing a qform transform, and the other a sform transform) which should display the corresponding .img files identically. (The data is stored differently in the .img files, but the transformations make them display consistently). Also, the origins should be identical. I have checked these files with MRIcroN (by Chris Rorden) and the NIfTI MATLAB toolbox (by Jimmy Shen, http://www.mathworks.com/matlabcentral/fileexchange/8797). In both these utilities, the images are displayed identically and with identical origin. However, when I load the images in SPM (5 or 8), the *qForm* image has an origin (in voxels) at [128.5 154.4 13.9] and the *sForm* image has an origin of [128.5 102.6 13.9]. When using the utilities above, the "correct" origin is the latter. Why is it that SPM is calculating a different origin for these images? Thanks! Bryce John Ashburner wrote: > SPM counts its indices in the same way as MATLAB, starting at 1 (like an > elevator does), whereas the actual encoding in NIfTI is in the C convention, > starting and 0 (as you see in a British lift). Unless I have made a mistake > somewhere, this should be the same throughout SPM. > > Apart from the imported images and flow fields generated by the DARTEL > toolbox, SPM only uses one of the matrices. When images are created by SPM, > both the sform and qform are set to encode the same transform (although some > qform transforms can not be exactly represented, and a warning message will > be generated). Images are written with their qform_code and sform_code both > set to 2. > > When orientations are read, the sform is used in preference to the qform. If > the sform is not specified, then the qform is used. If qform is not > specified, then SPM assumes that images are stored axially and their > left-right is determined by spm_flip_analyze_images. > > Best regards, > -John > > On Friday 13 March 2009 01:19, Bryce Wilkins wrote: > >> Hi everyone, >> >> I have been evaluating SPM 5/8's compatibility with the NIfTI standard and >> am curious to know the extent that the different transformations qForm and >> sForm embedded in the NIfTI header (either .hdr or .nii file) are >> accommodated in SPM. >> >> When I display a NIfTI file that includes a header with only the *sForm* >> transformation, SPMs "Display" utility seems to display it correctly, and >> the origin reported is as expected, say at [128 104 30]. However, when I >> load the same image data with a header that includes only the *qForm* >> transformation, I find the origin (and thus voxel space/world space) is >> incorrect; e.g. the origin is now reported as [128 154 30]. It seems only >> the second co-ordinate is wrong. >> >> If I display my test data sets with MRIcroN or a NIfTI MATLAB toolbox, the >> origin is reported identical as expected in all cases. >> >> So, my question is, does SPM 5/8 only support one type of transformation, >> either sForm or qForm. Which one should be used? >> >> Is the above inconsistency a bug that needs to be fixed? >> >> Thank-you for any comments to help me understand and resolve this problem! >> >> Regards, >> Bryce >> > >