# Why to invert the order of the indices between numpy and SimpleITK?

**URL:** https://discourse.itk.org/t/why-to-invert-the-order-of-the-indices-between-numpy-and-simpleitk/809
**Category:** Engineering
**Tags:** python, simpleitk
**Created:** [March 29, 2018, 8:13pm UTC](https://discourse.itk.org/t/why-to-invert-the-order-of-the-indices-between-numpy-and-simpleitk/809 "2018-03-29T20:13:04Z")
**Posts on this page:** 1
**Showing post:** 2

<div class="post-metadata">

### Author: ![blowekamp](https://discourse.itk.org/user_avatar/discourse.itk.org/blowekamp/32/79_2.png) [@blowekamp](https://discourse.itk.org/u/blowekamp)
#### Post date: [March 30, 2018, 2:09pm UTC](https://discourse.itk.org/t/why-to-invert-the-order-of-the-indices-between-numpy-and-simpleitk/809/2 "2018-03-30T14:09:15Z")

</div>

So `imshow` does correctly work with the layout that SimpleITK exports. Here is an RGB example:

```auto
In [14]: img = sitk.ReadImage("simpleitk_logo.png")

In [15]: nda = sitk.GetArrayViewFromImage(img)

In [16]: nda.shape
Out[16]: (53, 200, 4)

In [17]: img.GetSize()
Out[17]: (200, 53)

In [18]: plt.imshow(img)

```

The RGB channels ARE last.

The notebook example may be a little confusing because it is utilizing the size 3 for the z-physical space dimension, it is not an RGB image e.g. a 2-d image with 3 components. Additionally, imshow does not support 3-D spacial images, only 2-D image with 1,3, or 4 channels. The term depth in ambiguous here either referring to the number of channels or the 3rd spacial dimension.

The choices were not arbitrary. SimpleITK was designed to be consistent with ITK. ITK’s indexes are represented as x,y,z, so SimpleITK must reference the images that way too. The `GetArrayViewFromImage` method does not copy the ITK image buffer, so the layout of the data does not change when exporting. Numpy array created is index via C conventions (buffer[z][y][x][c]) vai [row major](https://docs.scipy.org/doc/numpy-1.13.0/glossary.html#term-row-major) with the fastest axis being the last “index”. So this approach is both efficient and compatible with numpy.

But you are correct it is error prone and confusing.

---

_[View the full topic](https://discourse.itk.org/t/why-to-invert-the-order-of-the-indices-between-numpy-and-simpleitk/809)._