Reluctantly, I have decided that it is now necessary to fully support oblique 3D volumes in AFNI, since more and more people are acquiring oblique partial-coverage EPI volumes and then want to overlay the FMRI results from these onto non-oblique anatomicals. There are essentially 2 approaches:
- (a) Transform everything to Talairach or MNI space and then everything is aligned (or at least, you can't overlay anything until you Talairach-ize). As far as I understand, this is what SPM and FSL do.
- (b) Allow arbitrarily oriented volumes to be overlaid and processed.
The more drastic (b) is what I lean towards, since it fits into the AFNI philosophy better. This approach leads to a host of problems and issues, some harder than others, and some as yet unforeseen:
- orientation in space will now be defined by a matrix, rather than a set of codes
- must deal with old dataset whose headers don't contain the matrix, just the codes (easy)
- must fix all dataset input and creation functions to make sure the matrix gets defined from all the formats AFNI supports (including MINC, NIFTI, CTF, ANALYZE)
- must examine all 1400+ places in the AFNI source code, in 100+ files, where the "daxes" sub-struct of a dataset is accessed in order to determine what the impact is at that location
- what to do about 3dZeropad? 3dresample? these are some of the programs that make special use of the orientation (e.g., '3dZeropad -I 7' adds 7 planes of 0s on the Inferior edge, but if the dataset is oblique, do we do the 'inferior-most' edge or just complain?)
- must fix the EDIT_dset_items() and EDIT_*_copy() functions so that defining and changing the axes is coherent
- 3drefit needs some changes
- what to do with an orientation matrix that is not a diagonal multiple of an orthogonal matrix (i.e., the 3 axes of the dataset are not perpendicular)? Complain? Use the nearest orthogonal set of directions? Or actually allow non-perpendicular axes (skewed volumes)? I do not like this last choice, Sam I am.
- the Matlab I/O functions must be modified to match the AFNI dataset header.
- the few non-SSCC users who write AFNI compatible code need to be informed so they can adapt their programs.
- Effect on realtime scanning?
I have started this process; last week, adding a matrix 'ijk_to_dicom' to the daxes sub-struct, and a function to load this matrix from the old orientation codes, and one to load the old orientation codes from the matrix, and an AFNI header attribute to store the matrix. The code is mostly in thd_matdaxes.c for now, but as more than 100 AFNI source code files refer to the daxes sub-struct, there will be a lot of changes coming down the pike. This will take a while, a long while, so I'm hoping to be able to incorporate the changes gradually. That's why I have the function that takes the matrix and computes the old orientation codes -- this will mean that compatibility with non-oblique datasets will be there even with as-yet unmodified code.
The next few steps I'm planning are geared towards overlaying obliques properly. There's some more invisible structural support that need building, and then the actual overlay business -- the return of warp-on-demand, since oblique datasets need to be interpolated to be displayed in the cardinal orientations of the AFNI windows. This in turn means I have to revisit the warp-on-demand code that I've carefully left untouched for about 9 years (I created it, but now I'm afraid of it -- the Frankenstein's monster of AFNI).
I don't know how long this will take. My enthusiasm for this is low, but I now feel it is required, and that I'm the only one who can do it since all the coordinate guts of AFNI are mine, built in from the very beginning in 1994.