Hi Alle Meije,

> I have now got a script that does what you suggested (ie use medcon to 
> make a 3D data set then run MriCRoN's dcm2nii to make nifti) and that 
> does the trick!

I've been playing with dcm2nii a bit, and it should be able to do the 
sorting itself, including correctly making separate NIfTIs from 
directories that contain unsorted slices from different volumes. This 
should be more reliable than my suggestion of stacking with medcon, 
since it's possible to mis-order the files when stacking.

If dcm2nii fails for your particular data, I'd suggest contacting 
Chris Rorden, to see if the problem can be fixed.

> Chris Rorden has a very nice page that explains of dcm2nii is swap-aware 
> (between DICOM and NifTI/Analyze, it's apparently like reading Arabic 
> vs. reading English!).

I had a quick look, and couldn't find that, could you post the URL, 
please?

>  From what I see dcm2nii does not seem to do sorting, rather put in an 
> S-form matrix. This is typically what I thought should be in the Q-form 
> (scanner -> raw image: Q-form and raw image -> template: S-form) but it 
> allows me to keep left/right intact for now.

I think the NIfTI spec is fairly flexible about which mapping goes in 
either/both of the Q/S-form. The header does contain the comment
   "a dataset would originally be set up so that the Method 2
    coordinates represent what the scanner reported.  Later,
    a registration to some standard space can be computed and
    inserted in the header"
but I believe it's quite possible under the standard to specify 
"scanner anatomical" intent for the sform and MNI for the qform. The 
latter might be a bad idea, since the qform can only represent a 9 DF 
transformation (with no shearing of axes) whereas the sform can 
represent a full 12 DF affine transformation. But the former -- having 
scanner-anatomical coords in the sform -- seems fine.

[I don't actually know why the more limited qform is present, instead 
of offering two sform-type transformations; I'd guess there might have 
been some motivation to use quaternions to represent rotation, but I 
can't see why an optional skewing couldn't have followed that, but 
anyway...]

For more info, search for "WHY 3 METHODS" and NIFTI1_XFORM_CODES in:
http://nifti.nimh.nih.gov/pub/dist/src/niftilib/nifti1.h

> Another reason for being afraid of SPM is that apparently Templaye == 
> MNI, so I'm not sure what happens if I use a coronal template, or one 
> that's x-flipped wrt the MNI template? Does either SPM or FSL allow for 
> these `deviations from normality'?

The benefit of having a voxel-world mapping and then working in voxel 
coordinates is that this kind of thing shouldn't matter any more. You 
can, for example, use SPM5 to reorient your image to be aligned to MNI 
world-space, without resampling the voxel data. It doesn't matter 
whether the two fastest-changing voxel dimensions give an axial or 
coronal plane, as long as the voxel-world mapping in the Q/S-form 
gives (x,y,z) mm coordinates that are aligned with MNI.

At the moment, FSL doesn't really fully support NIfTI 
world-coordinates. FSLview uses them to label its axes (which is 
extremely helpful BTW!) but tools like FLIRT don't currently take 
account of them, so you might need to use e.g. avwswapdim to roughly 
align your data with your desired template.

>> Note these are both right-handed coordinate systems, but I think the 
>> determinant of the Q/S-form can be positive or negative negative 
>> depending on the handedness of the voxel storage convention in NIfTI. 
>> While it sounds to me that DICOM should always have a right-handed 
>> voxel storage order
>>   http://nifti.nimh.nih.gov/board/read.php?f=1&i=532&t=508
>> where I understand from the FAQ that the fastest changing voxel index 
>> is along the rows (i.e. column index i), followed by down columns (row 
>> index j), and then slice (k) is slowest changing. I.e. Voxels[k][j][i] 
>> in C++ notation
>>   http://www.vtk.org/Wiki/Proposals:Orientation
>>   http://grahamwideman.com/gw/brain/orientation/orientterms.htm
> 
> ... you seem to have stopped here mid-sentence?

No, just forgot the full-stop after notation. So far, no-one has 
replied to me (hopefully anyone who does will go via (or CC) the list) 
about this, so I'm still a little confused. But maybe the stuff you 
found on Chris Rorden's webpage might clear this up for me...

> I wonder how FSL and SPM compare in that respect? What would happen if I 
> combine an acquisition with axial slices, and an acquisition with 
> coronal slices, in the same study?

I think this would probably be a bad idea, due to things like MR 
gradient non-uniformities and differences in motion/pulse artefact, 
etc. But I'm only guessing here -- MR Physicists, feel free to shout 
at me!

But, yes, if the Q/S-form is set correctly the images should appear 
roughly in register programs such as SPM5's check reg, and MRICron. 
FSLview refuses to load overlays that don't have matching voxel and 
image sizes though.

HTH,
Ged