Hi Alle Meije,
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...)
> By the looks of it though dinifti looks less automated than medcon.
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.
> The reasons that I have saved SPM5 until last are: the fact that it's
> not scriptable (well, matlab.. sort of..) and the fear of ruining
> everything with .mat files!
Actually the .mat files are mainly an SPM99/2 thing. I think SPM5's
DICOM import should correctly store the orientation information in the
NIfTI headers in the standardised way. [SPM5 does seem to still
generate .mat files for 4D NIfTIs, presumably so it can potentially
have different voxel-world mappings for each 3D volume within the
series, which NIfTI doesn't allow, to the best of my knowledge. This
might be useful for e.g. incorporating motion-correction
affine-transforms in the headers. Anyway, I digress]
> It would be great to have the S-forms and/or Q-forms filled in. To an
> extent, FSL does this.
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.
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
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
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...
Well, I'd better stop there, best of luck!
Ged
|