Hi Ged,

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!
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!).
Nice to know also that although medcon is not sawp-aware, it does seem 
to retain the information necessary dor dcm2nii to keep the orientation.

> MRIConvert and/or mri_convert (!) sound like they should be perfect, but 
> I'd like to respond to some things for completeness (and ask a few 
> things to the experts, while I'm at it...)

Haven't yet been able to get them to work...

> Last time I checked medcon, the -stack3d command just put the slices 
> into a volume *in the order you specified them* on the command-line. If 
> for your data, specifying them in the right order is trivial, then cool, 
> but this isn't always true. MRIConvert, mri_convert, and others 
> including SPM5, and I believe dinifti try to do some automatic sorting, 
> so I think
>   dinifti /path/to/dir_full_of_dicoms nifti
> should produce nifti.nii from unsorted DICOMs.

 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.

If it gets to resampling to a template, I may still need to use other 
tools, i.e. ones that re-order the data in the way you say.

Therefore: still very intersted in evidence that one of these tools does 
the job!

> But this path (via Analyze) fills the Q/S-form based on just the voxel 
> dimensions and origin, and I believe some slightly arbitrary assumptions 
> about flipping Analyze images and/or negative pixel dimensions. I don't 
> think you can be confident that the resulting images have the correct 
> left/right orientation. Certainly the DICOM information about the exact 
> alignment of the axes (e.g. from the ImageOrientationPatient direction 
> cosines) is lost, since Analyze can't store this info.

That was true for my previously described method. The dcm2nii approach 
seems to do the orientation matrix right.

> By going directly from DICOM to NIfTI this should be handled better, 
> though I think there are still some slight complications, which it might 
> be interesting for experts like Jolinda/Doug/Andrew to comment on 
> (thanks in advance if you can find the time). E.g. I believe DICOM often 
> has increasing (x,y,z) aligned with increasing (left,posterior,superior) 
> while NIfTI has increasing (x,y,z) aligned with increasing 
> (right,anterior,superior).
> 
> http://www.faqs.org/faqs/medical-image-faq/part2/
> http://nifti.nimh.nih.gov/pub/dist/src/niftilib/nifti1.h

True. Well I guess for the images that I have now it depends on the 
normalisation program to compare the image's  coordiniate system with 
the template's and do the necessary things.

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'?

> 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?

> Sorry, Alle Meije, if I am making this thread even more complicated! But 
> I'm slightly worried that different people might have done different 
> things with regard to the apparent differences between the DICOM and 
> NIfTI orientation conventions in writing their converters. There is the 
> added complication that other software has different conventions for 
> matrix storage order, e.g. Matlab has Array(row,col,slice) or 
> Voxels(j,i,k) based on the above interpretation of DICOM. Hmmm...

This is true.

Again, this should all be solved for programs that make use of the nifti 
orientation matrices in their most general form (ie axial as well as 
saggital and coronal images) and apply them in an unambiguous way (ie 
not mixing up the role of Q-form and S-form).

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?

Has anyone tried?

With best wishes,
Alle Meije