Slicer 4.9.0-2017-11-29 r26666
Linux Mint 18.2 64-bit
Hello all,
It is a very helpful feature to be able to read/write MINC2 files directly in slicer. However, I noticed an unexpected behavior when loading MINC2 files: the image is oriented in a wrong direction.
First, when loading the image using ITK, the image is loaded properly, with an identity direction matrix.
Then, when loading the image using slicer, the volume direction matrix is rotated 180° around IS axis. As far as I know, MINC2 format uses the RAS orientation convention, which makes me believe that slicer considers the default orientation of minc files as LPI (not sure?) and re-orients the image to RAS.
I converted the image to a NIfTI file, then slicer reads it properly (volume direction has identity matrix)
My questions are:
am I missing something about the image orientations?
is it possible to turn off the automatic re-orientation to RAS in slicer?
is it a bug of slicer misinterpreting the MINC2 orientation?
In all commonly used image file formats (nrrd, metaimage, nifti, etc), coordinate system (LPS, RAS, …) is specified in the file header. Does MINC2 files have this information in its header or MINC2 is hardcoded to always use RAS?
The MINC2 “world” coordinate system is always supposed to be in RAS. However, the x,y,z image coordinates can be stored in different order on the disk, the order is specified in the header’s tag
image:dimorder = "zspace,yspace,xspace" ;
I wonder if this is handled by the ITK reader filter.
ITK loads MINC files in the correct orientation, i.e., RAS. I believe slicer is assuming by default that the image is in LPI and re-orient the images. Is it possible to have slicer leaving the orientation as loaded by ITK?
In general, ITK loads all images as LPS. If it loads MINC files as RAS then it may be an error. We can easily compensate for this inconsistency in Slicer but this would be better clarified with maintainer of MINC IO in ITK.
@thewtex do you know if MINC reader behavior is intentional?