Hello! I need a little advice about a nonstandard usage of spm tools.
Motivation: My group uses various servers to store files, and reading/writing to and from these servers ends up taking as much or more time than actual computations in our preprocessing/processing scripts -- which heavily use spm functions. My idea was to extend the spm header created by spm_vol to include fields for an image, b-value, b-vector, and more. This way all data can stay within Matlab (and are actually easier to manipulate). Crucially, I noticed that all my necessary spm functions could take in "double-precision floating point arrays". So I modified each relevant function to use numerical arrays instead of the normal spm_vol structures; this included spm_slice_vol and spm_bsplinc primarily, because these two were used in spm_coreg, spm_reslice, and spm_read_vols. Everything seemed to be working great until...
Setup: I noticed that the affine transform produced by spm_coreg was slightly different when used the standard way and when I modified it to use a numerical array. Like maybe a 1% difference. But I'm afraid my group won't accept my changes to the pipeline unless it performs exactly like the old way or I understand and communicate why it's different.
**Actual Question**: Will spm_slice_vol (for instance) perform any differently when given a numerical array versus an spm_vol header? It seems like it would be the same if the header just loads up a numerical array from disc, but I'm worried that spm_slice_vol also uses some header information (like the qform voxel to mm/"voxel to world" representation/transformation matrix).
Additional info: I ask about spm_slice_vol because I think I've narrowed the differences in spm_coreg usage down to this function*. I use spm_coreg like normal, except that I put a .img field into the header (alongside .dim, .mat, .fname, etc). The only places in the function that seem to use the actual image volume are load_uint8>spm_slice_vol. Everywhere else I leave things as they were.
Right now I'm in the process of going through the source/C code and trying to figure out exactly how the two cases are handled. The function "get_maps" and the functions it calls (get_maps_struct, get_maps_3dvol, and get_maps_dat) seem to be crucial. But I can't tell if 1. get_maps actually grabs the voxel data or 2. if the matlab header field .private.dat actually contains the image volume information (essentially the whole trick I was trying to pull). If you look at (spm_vol struct).private, it describes .dat as a "[dim1]x[dim2]x[dim3] file_array", but I can't tell in what sense ().private.dat is an 3D array, as trying to access it in matlab just gives you more fields of strings and 4x4 matrices.
Anyway, any insight would be useful. If you need to ask clarifying questions, please go ahead. I'm just stumped as to why the two cases produce different results. I am still looking into this, but figured I would shoot off this email because I think figuring it out will take a long time; I don't know much C and I'm a lowly Research Specialist I.
Thanks for reading!!!
Andrew Taylor
[log in to unmask]
*Note: I have not completely ruled out the fact that my former frequent rewriting of volumes may have resulted in a header info sanitization by spm's read/write algorithms; and maybe I've accidentally changed what I thought of as an unimportant part of the header, which resulted in different coregistration results. For instance, I don't fully understand the .pinfo field and don't know if this field is rescaling my data at some point without my knowledge.
|