# MINC2 Reader and RAS coordinate system

**URL:** https://discourse.slicer.org/t/minc2-reader-and-ras-coordinate-system/2524
**Category:** Development
**Tags:** coordinates, file-import
**Created:** [April 5, 2018, 8:34pm UTC](https://discourse.slicer.org/t/minc2-reader-and-ras-coordinate-system/2524 "2018-04-05T20:34:58Z")
**Posts on this page:** 8
**Page:** 1

<div class="post-metadata">

### Author: ![hgueziri](https://avatars.discourse-cdn.com/v4/letter/h/a587f6/32.png) [@hgueziri](https://discourse.slicer.org/u/hgueziri)
#### Post date: [April 5, 2018, 8:34pm UTC](https://discourse.slicer.org/t/minc2-reader-and-ras-coordinate-system/2524/1 "2018-04-05T20:34:58Z")

</div>

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?

Thanks

---

<div class="post-metadata">

### Author: ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)
#### Post date: [April 6, 2018, 12:37am UTC](https://discourse.slicer.org/t/minc2-reader-and-ras-coordinate-system/2524/2 "2018-04-06T00:37:35Z")

</div>

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?

---

<div class="post-metadata">

### Author: ![hgueziri](https://avatars.discourse-cdn.com/v4/letter/h/a587f6/32.png) [@hgueziri](https://discourse.slicer.org/u/hgueziri)
#### Post date: [April 6, 2018, 3:11pm UTC](https://discourse.slicer.org/t/minc2-reader-and-ras-coordinate-system/2524/3 "2018-04-06T15:11:52Z")

</div>

Hi Andras,

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.

---

<div class="post-metadata">

### Author: ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)
#### Post date: [April 6, 2018, 3:16pm UTC](https://discourse.slicer.org/t/minc2-reader-and-ras-coordinate-system/2524/4 "2018-04-06T15:16:32Z")

</div>

I’ve checked Slicer source code and MINC file loading is handled completely by ITK. We use whatever orientation ITK provides. While we could add workarounds at Slicer level, if you find any errors then best would be to report and fix in ITK. See ITK’s MINC image reader implementation here: [https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/IO/MINC/src/itkMINCImageIO.cxx](https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/IO/MINC/src/itkMINCImageIO.cxx)

---

<div class="post-metadata">

### Author: ![hgueziri](https://avatars.discourse-cdn.com/v4/letter/h/a587f6/32.png) [@hgueziri](https://discourse.slicer.org/u/hgueziri)
#### Post date: [April 11, 2018, 6:04pm UTC](https://discourse.slicer.org/t/minc2-reader-and-ras-coordinate-system/2524/5 "2018-04-11T18:04:43Z")

</div>

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?

---

<div class="post-metadata">

### Author: ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)
#### Post date: [April 12, 2018, 7:42pm UTC](https://discourse.slicer.org/t/minc2-reader-and-ras-coordinate-system/2524/6 "2018-04-12T19:42:34Z")

</div>

> [@hgueziri](#):
>
> ITK loads MINC files in the correct orientation, i.e., RAS

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?

---

<div class="post-metadata">

### Author: ![thewtex](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/thewtex/32/32_2.png) [@thewtex](https://discourse.slicer.org/u/thewtex)
#### Post date: [April 12, 2018, 8:13pm UTC](https://discourse.slicer.org/t/minc2-reader-and-ras-coordinate-system/2524/7 "2018-04-12T20:13:19Z")

</div>

Yes @lassoan is right – if the MINC reader is loading the image in RAS instead of LPS, then it is not intentional and it signals a bug.

---

<div class="post-metadata">

### Author: ![thewtex](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/thewtex/32/32_2.png) [@thewtex](https://discourse.slicer.org/u/thewtex)
#### Post date: [April 12, 2018, 8:16pm UTC](https://discourse.slicer.org/t/minc2-reader-and-ras-coordinate-system/2524/8 "2018-04-12T20:16:10Z")

</div>

It sounds like the `itk::Image` `Direction` should account for RAS -\> LPS.
