Q:Hi all, I’m playing with a MINC volume that was converted from DICOM, which has some unusual direction cosines, and entering both volumes, MINC and DICOM, with ITK importers. I’m finding that there is a difference in min and max coordinates, and I’m having trouble ascertaining where the trouble is.

For example, when typing mincheader, one sees the line: dicom_0×0020:el_0×0032 = “-26.902344\\−197.40057\\−45.887484” ;

which mostly coincides with what I see when we load the data in DICOM format:
minx: −26.9 maxx: 75.5
miny: −197.4 maxy: −95.2
minz: −51.89 maxz: −12.59
Other data in mincheader include:
xspace:step = −0.1953125 ;
xspace:start = 26.80468775 ;
xspace:direction_cosines = 1., 0., 0. ;

               yspace:step = −0.1953125 ;
                yspace:start = 193.094103137385 ;
                yspace:direction_cosines = 0., 0.99691733368886, 0.0784590962903196 ;

               zspace:step = 0.299075200106658 ;
                zspace:start = −67.2154025304974 ;
                zspace:direction_cosines = 0., −0.0784590962903196, 0.99691733368886 ;

doing a mincinfo produces
maudette at icaw164201:~/data/work/earWork/goodEarData> mincinfo etzold_emma_12792115_003002_mri_xyz.mnc
file: etzold_emma_12792115_003002_mri_xyz.mnc
image: signed__ short −32768 to 32767
image dimensions: xspace yspace zspace
dimension name length step start

   --------------         ------         ——        -----
   xspace                    512    −0.195312      26.8047
   yspace                    512    −0.195312      193.094
   zspace                    129     0.299075     −67.2154

We implemented a program that inverts the sign of step and start if the step is negative, from a minc import, and it produces
minx: −26.8 maxx: 73
miny: −197.77 maxy: −97.97
minz: −51.86 maxz: −13.58
Can anyone help me make heads or tails of this discrepancy?

How does a dicom to minc conversion produce negative spacing in x and y, and can this converter make a mistake with start and spacing size? Does it round off anything, or is it sensitive to non-standard cosine angles?
http://www.bic.mni.mcgill.ca/pipermail/minc-users/2008-August/002159.html

A: I guess im having a little trouble determining if the problem exists solely in the tool you are implementing, or in the DICOM/minc conversion, or both. But i will hazard a guess anyway that it may be due to the way MINC defines its coordinate system.

if A is the rotation matrix, S is a diagonal matrix of the step sizes, and O is the start, as listed by mincinfo, then the position of the center of pixel X, in minc world, is

A*S(X+O)

In ITK, and possibly in DICOM, but i am not sure, the coordinate system is defined as. A*S*X+O

The point being that in the minc case the start/origin, as such, is not the coordinate of pixel zero, while in ITK world it is. In the minc world the origin is an offset parallel to the pixel axes. When the direction cosines are not the identity matrix, then this makes a big difference. Some of the small discrepancy in the coordinates looks like it could be due to that.

But if you want to get rid of negative spacing, you either have to reorder the data, or multiply the relevant direction cosines by −1. AND switch the start/origin accordingly - i dont think you want to just invert its sign, i think you want to swap it with the other corner. Multiplying the direction cosines could change the coordinate system from right to left handed, which might or might not cause problems, im not sure.

Oh - if you use my formulas above, please check em… its late here.