[MINC-users] dcm2mnc produces xspace:spacing = "irregular"

[Andrew Janke]

>  Sure.  But your problem is not with DICOM per se, but rather with
>  interpreting the vendor private attributes that presumably define the
>  slice positions.  I've never seen a mosaic image; I'd be interested to
>  have a look if you have an example handy.

Completely agree.  In most cases I suspect this is because the
manufacturers wanted to do more with DICOM that they could easily
implement.  Siemens "Phoenix" technology for example.  Thus they added
their own data in there.  Do a string search for ASCCONV in you
Siemens dicom data for example.. :)

   http://www.enac.northwestern.edu/~tew/archives/2003/02/25/incomplete-dicom-headers/

Has a nice explanation of some of the mosaic issues.

>  You could rightly argue the problem stems from DICOM not having a
>  useful 3D or 4D format when fMRI was developed.  Now that they have
>  the Enhanced MR IOD, is anyone using it for fMRI?

I would bet they stuck with what they know. :)  Haven't looked too
much further though, we tend to just keep patching dcm2mnc as needs
arise.  We are certainly not alone though, nearly all the DICOM
converters out there contain a massive case statement that is
essentially a switch on the (hardware/software) source of the data.

>  Both these examples, however, are a far cry from "some scanners use
> origin/angle, some use absolute position of centre of slices, some use
>  offsets, etc", which is what I was curious about.

Correct, in this case I was referring to Mosaic formats.


a