> Plus, are you sure that these programs estimate the position of a volume
> using the positions of individual slices?
Well I do know that from having written a fair amount of dicom
conversion code that in some cases it is ambiguous from the headers as
to just where the origin of the data is (or what the step is even --
from a manufacturer who will not be named). In these cases the only
fall-back you have to use the information from each slice that
describes the position and up-vector of each slice. From this you
average the gaps between the adjacent slices if they fit within a
certain delta and go from there.
> I tried the links, but none of them actually gave useful information in
> terms of: this is your DICOM cd, and this is how you rip your volumes
> off it...
>
> Any advice is still much appreciated, and if those programs really come
> up with Q-forms from slice data, I'm very impressed!
My advice if you are getting data from a bunch of different DICOM
"based" scanners is to use a "homogenization" approach..... What I
mean by this is to rely on others (much larger) groups to read the
DICOM correctly and then convert from the output of that particular
program. The best tool for this that I have seen on the free market is
Osirix (by about 3 light years). It is a complete DICOM
server/client/router/etc meaning you can just install it and then send
your data to it (push or pull) from your scanner. No need to worry
about export to CD vs export to DB, etc etc.
Then you define a nice folder action or Automater script that calls
the Export function in Osirix. I have found that it does a fantastic
job of cleaning up CDs as you describe and cleaning up headers. You
then only need to figure out one method for converting your data from
Osirix to Nifti/MINC/AFNI/etc.
Pity Osirix it is Mac only (so far). :)
--
Andrew Janke ([log in to unmask] || http://a.janke.googlepages.com/)
Canberra->Australia +61 (402) 700 883
|