Hi Ged,

The answer to this question probably needs to be answered in terms of 
the NifTI header.

Ged Ridgway wrote:
> Hi John or anyone else who can help,
> Can you clarify the behaviour of spm_flip_analyze_images (set from 
> defaults.analyze.flip or to 1 if the defaults global variable doesn't 
> exist) in SPM5?
> Should it ever be used after spm_vol has returned a structure with a 
> matrix? For writing images for example? Or is the vol.mat treated as 
> correct, once this has been set from spm_vol.
> Is it only used on true Analyze images, and not on single volume .nii or 
> on two-volume hdr/img NIfTI pairs?
> It appears not to be used if the second pixdim is negative, (judging 
> from @nifti/private/mayo2nifti1.m) but I'm not exactly sure for which 
> images mayo2nifti1 is called, or where this pixdim comes from.
> It seems to me that an image should remain the same if the voxel data is 
> flipped AND the matrix is also altered, but as far as I can tell from 
> mayo2nifti1 this behaviour could break down if someone had 
> defaults.analzye.flip = 1. If image1 has negative pixdim, SPM will read 
> it without flipping, but if image2 has flipped voxel data and a flipped 
> matrix (hence should be equivalent to image1) SPM will flip the image, 
> giving the wrong handedness cf. image1.
> This is a bit of a special case, I know, but I just wanted to check...

In principle, the NifTI header field sto_xyz (the S-form) expresses the 
image's coordinates in terms of another image's coordinates (such as a 
template).

With NiFTI, you shouldn't have to worry anymore about 
radiological/neurological, right-handed/left-handed and all those 
nightmares -provided the matrices of your input images were set 
correctly when they came from the scanner of course!

The signs of the image's x,y,z voxel sizes can all be pos/neg, making 
the signs of its x,y,z ofsets neg/pos (other sign as the voxel size) -to 
guarantee that the centre of gravity is inside the field of view!
The same goes for the MNI templates of course, and the x,y,z voxel sizes 
have signs -,+,+ (and so the offsets have signs +,-,-).

If your image's x voxel size has sign +, then it needs to be swapped in 
the x direction to be overlayed on the template, if its y voxel size has 
sign -, it needs to be swapped in the y direction, and if the z voxel 
size has sign -, then it needs swapping in the z direction.

As you can see, the need to flip is only dependent on which template you 
use, and is only used on normalisation (never before and never after).

> Also, in John's reorient.m
>   http://www.sph.umich.edu/~nichols/JG5/reorient.m
> and consequently in my previous version of resize_img.m which was based 
> on this, there is the following:
> 
>   tc = V.mat(1:3,1:4)*c;
>   if spm_flip_analyze_images, tc(1,:) = -tc(1,:); end;
> 
> this seems wrong to me now, since if the flipping behaviour has been 
> used already to set V.mat, then tc would seem to be correct, before it 
> is altered.

I'm not sure, but I think that spm_flip_images() is called in spm_vol(). 
That means that spm_flip_analyze_images is only true on the first call 
to spm_vol (when you create V.mat), and never after that.

Once again, in NifTI images it should not be necessary to have a .mat 
file -everything can be stored in the S-form of the NifTI header!

> determinant as the input. Right? I like the fact that this approach 
> would just let spm_vol worry about analyze.flip, and assume that it does 
> the right thing, but perhaps I am missing a reason why it is important 
> to reconsider analyze.flip when reslicing?

I think analyze.flip is only relevant to analyze images. You should not 
have to bother with it (or indeed the cursed .mat files!) with NifTI images.

> Sorry for such a long (and boring -- I know everyone hates orientation 
> issues) email, thanks very much for any help anyone can offer,

Well as said, they were a curse in the Analyze age. It should be history 
with NifTI, but only if

-you know that your S-form matrix is properly set (for the raw images)
-you don't use .mat files

Example:
our images come from the scanner with S-form
-voxx 0 0 +offx
0 -voxy 0 +offy
0 0 +voxz -voxz
so compared to the MNI template, which has S-form
-voxx 0 0 +offx
0 +voxy 0 -offy
0 0 +voxz -voxz
only a y-swap is necessary in the normalisation.

So you need to do the checks on the S-form of your raw data, but after 
that you should be sweet.

With best wishes
Alle Meije