> Well, find attached my latest script, i.e.
>
> DICOM slices -> DICOM 3D
> DICOM 3D -> NifTI 3D
>
> Which leaves all the matrices in, shows the coronal scan as a coronal
> scan, and shows the head upright instead of upside down :)
It looks like your script is just sorting the filenames in
alphanumeric order. As I mentioned before, with some data sets this is
fine, I think it can go wrong with others, but if it works with your
data then it's probably fine.
However, note that whether the head is the right way up is neither
necessary nor sufficient for the volume to be correct. It's very
important to check that left/right orientation is correct, and you
cannot do this just by looking at the images. E.g. you can have data
which FSLview loads such that the coronal picture is upside down, but
for which FSLview correctly labels inferior/posterior etc. (SPM's
check reg shows images in world space, so here the coronal image
should be the right way up AND the correct way round in terms of
left/right). On the other hand you can have data for which all three
views look fine in FSLview or SPM, but for which the left/right
convention indicated by the Q/S-form is actually reversed compared to
reality. The only way you can really be 100% certain of this is by
scanning someone will vitamin/oil capsule on the right side of their
head, and checking that it is labelled R by FSLview, or on the right
in SPM check reg.
I think this is particularly important with your medcon pipeline,
programs like dcm2nii (or the SPM5 dicom import) try hard to ensure
the orientation is correct when stacking slices, but medcon just goes
by the order you give it, and the filenames might not be in the
correct order within the directory (depending on things like how the
data was acquired, and what scanner/PACS you have, etc).
> Ah. I thought that Q-form and S-form had different roles. I usually try
> to leave the Q-form alone, and doing all the standard space work in the
> S-form.
I think a lot of people treat it like that, but the standard does let
you specify your "intent" for either.
>> [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...]
>
> The only explanation I can offer is that the Q-form represents the
> orientation in the scanner...
Yeah, I'm sure you're right, but then I don't know why they let you
specify intent codes, rather than just stipulating that Q is scanner
and S is template. I think it is true though that the scanner coords
are almost never skewed. [I've a vague memory of someone (John
Ashburner or Volkmar Glauche maybe) saying that is possible though...]
> Ah, and it is possible to do your analysis in these `world' coordinates
> without resampling to standard space?
Well, I'm pretty certain that it should be possible, but I don't think
SPM actually does this. It does allow the mask image to have different
voxel and image dimensions, and takes into account the difference
between the result's voxel-world mapping and the mask's. But it
doesn't do the same for the input volumes; it seems to expect them to
be registered in voxel-space. FSL, as I mentioned before, doesn't use
the voxel-world mapping outside of the FSLview labelling. But I think
either program could probably be adapted to use the Q/S-form and
interpolate the voxels to find the data at any world location, as it
went along.
An important point here though is that SPM is often used to perform
non-linear spatial normalisation. It would be possible to store these
parameters (though not in the NIfTI Q or S form, obviously) and read
the data in a similar way, but that doesn't really happen anywhere in
SPM, to the best of my knowledge.
Perhaps the main reason for resampling before statistical analysis is
that Gaussian smoothing is much faster and easier to implement if the
three voxel dimensions can be separably smoothed, ignoring where the
voxels map to in world space.
> If so, I wonder what format the computed maps will have...
Whatever you want! You can define the numbers of voxels in your
output, and a mapping from these to world coordinates. Then you can
use this mapping, and the mappings for each input image to read the
corresponding voxels from the input, compute the result, and write it
out. This is basically what my resize_img program for SPM does, in
order to write out data with a given voxel-size and world
bounding-box. It could be adapted to write out data in e.g. coronal or
an oblique rotation, if you really wanted to...
http://www.cs.ucl.ac.uk/staff/G.Ridgway/vbm/resize_img.m
> Well, I was more thinking of re-ordering an axial image as a coronal
> image, changing the orientation matrix appropriately and then see if any
> of the analysis programs survives...
If you did this in SPM5, you should find that check reg shows the
images identically. You'd have to reslice the images, e.g. by
spatially normalising them, before proceeding with the analysis, but I
think it would be fine (if somewhat bizarre to want to do!).
But this doesn't mean that you shouldn't bother getting the
DICOM->NIfTI orientation right, since when it comes to interpreting
your results, you want to know that the blobs labelled "left" are
actually on the left of the subject(s)'s brain!
Sorry to go on about this, all the best,
Ged
|