Hi there,

Does anyone knows what is going on with one of the internal
information stored in CSA header for a SIEMENS MOSAIC instance:
SliceNormalVector ?

There are references in your codebase that this 3D vector indicate
that the order of the slices may be in opposite order:

* https://github.com/neurodebian/spm12/blob/master/spm_dicom_convert.m

[...]
    % Maybe flip the image depending on SliceNormalVector from 0029,1010
    %-------------------------------------------------------------------
    SliceNormalVector =3D read_SliceNormalVector(hdr{i});
    if det([reshape(hdr{i}.ImageOrientationPatient,[3 2])
SliceNormalVector(:)])<0;
        volume =3D volume(:,:,end:-1:1);
        mat    =3D mat*[eye(3) [0 0 -(dim(3)-1)]'; 0 0 0 1];
    end;
[...]

However when I load one particular instance, here is what I see:

$ gdcmdump --csa mosaic.dcm | grep SliceNormalVector
23 - 'SliceNormalVector' VM 3, VR FD, SyngoDT 4, NoOfItems 6, Data
'0.00000000'\'0.00000000'\'-1.00000000'

Which is indeed in opposite direction as one would have expected from
the normal vector to the Direction Cosines:

$ gdcmdump mosaic.dcm | grep Orientation
(0020,0037) DS [1.0\0.0\0.0\0.0\1.0\0.0 ]                         #
24,6 Image Orientation (Patient)

In this case the normal is obviously: (0,0,1). So this correspond to
the code section I am showing above..

At this point, it would make sense to reorder the slices contained
within the 2D frame in opposite order (per SPM codebase).

But if one inspect more of the SIEMENS CSA ASCCONV attributes (within
MrProtocol subsection), one can see the following:

$ gdcmdump --csa mosaic.dcm | grep sSliceArray.asSlice | grep sPosition
sSliceArray.asSlice[0].sPosition.dSag    = -9.322033898
sSliceArray.asSlice[0].sPosition.dCor    = -35.59322034
sSliceArray.asSlice[0].sPosition.dTra    = -91.54661017
sSliceArray.asSlice[1].sPosition.dSag    = -9.322033898
sSliceArray.asSlice[1].sPosition.dCor    = -35.59322034
sSliceArray.asSlice[1].sPosition.dTra    = -89.04661017
[...snip...]
sSliceArray.asSlice[58].sPosition.dSag   = -9.322033898
sSliceArray.asSlice[58].sPosition.dCor   = -35.59322034
sSliceArray.asSlice[58].sPosition.dTra   = 53.45338983
sSliceArray.asSlice[59].sPosition.dSag   = -9.322033898
sSliceArray.asSlice[59].sPosition.dCor   = -35.59322034
sSliceArray.asSlice[59].sPosition.dTra   = 55.95338983

Clearly it seems as if the slices from the 2D frame are ordered in the
correct normal direction: (0,0,1).

One can even check the normal associated with those slices:

$ gdcmdump --csa mosaic.dcm | grep sSliceArray.asSlice | grep sNormal
sSliceArray.asSlice[0].sNormal.dTra      = 1
sSliceArray.asSlice[1].sNormal.dTra      = 1
[...snip...]
sSliceArray.asSlice[58].sNormal.dTra     = 1
sSliceArray.asSlice[59].sNormal.dTra     = 1

So again the normal associated with the slices is (0,0,1).

In conclusion: what the heck is SliceNormalVector ? How does one
traverse the slices stored in a 2D frame from a SIEMENS MOSAIC dataset
? Who ever wrote that code originally must have had a good reason to
do so, in which case is there a way for me to double check this
assumption (normal is opposite) is also correct for my DICOM file ?


Just for completeness the Image Position (Patient) for this instance is:

$ gdcmdump mosaic.dcm | grep Position
(0020,0032) DS [-969.32203388214\-995.59321975708\55.953388214111 ]
    # 50,3 Image Position (Patient)

Thanks much !
-- 
Mathieu