# Input Orientation and Axis Indexing in PyRadiomics (SimpleITK vs NumPy)

**URL:** <https://discourse.slicer.org/t/input-orientation-and-axis-indexing-in-pyradiomics-simpleitk-vs-numpy/42332>\
**Category:** Radiomics\
**Created:** [March 27, 2025, 5:14pm UTC](https://discourse.slicer.org/t/input-orientation-and-axis-indexing-in-pyradiomics-simpleitk-vs-numpy/42332 "2025-03-27T17:14:18Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![joshuacwnewton](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/joshuacwnewton/32/79971_2.png) [@joshuacwnewton](https://discourse.slicer.org/u/joshuacwnewton)\
**Post date:** [April 11, 2025, 4:57pm UTC](https://discourse.slicer.org/t/input-orientation-and-axis-indexing-in-pyradiomics-simpleitk-vs-numpy/42332/6 "2025-04-11T16:57:50Z")

</div>

> [@valosekj](#):
>
> - `0` == `x` == axial == Superior-Inferior
> - `1` == `y` == coronal == Anterior-Posterior
> - `2` == `z` == sagittal == Right-Left

Just popping in to try to clarify what @valosekj is referring to by the above quote.

> [@pieper](#):
>
> Just to restate what I said earlier, the 0, 1, 2 and x, y, z in image space that you are referring to do not correspond to any particular world space direction or slicing plane. That mapping is defined by an affine matrix.

We’re coming from the world of NIFTI1 images, `nibabel`, and FSL (specifically tools like the FSLeyes image viewer and `fslhd`). As far as I understand:

- For `nibabel` and FSL, affine matrices are assumed to [always map the voxel array to RAS+ world space](https://nipy.org/nibabel/coordinate_systems.html#the-affine-matrix-as-a-transformation-between-spaces).
- However, in voxel space, the array can be “reoriented” (i.e. axes transposition and inversion). For FSL, this can be done with `fslswapdim`. In order to preserve the “always maps to RAS+” assumption, if the data array is changed, then the affine will be changed in kind.
- The tool `fslhd` reports the header information in NIFTI1 image files. Part of the output information is the axis ordering corresponding to the qform/sform affine matrices. For example, on a sample image I’ve picked out, the command reports:

```auto
sto_xyz:1 0.000000 0.000000 1.000000 -32.219284 
sto_xyz:2 -1.000000 0.000000 0.000000 31.786606 
sto_xyz:3 0.000000 1.000000 0.000000 -19.321671 
sto_xyz:4 0.000000 0.000000 0.000000 1.000000 
sform_xorient Anterior-to-Posterior
sform_yorient Inferior-to-Superior
sform_zorient Left-to-Right

```

- Because of this information, our lab will refer to such images in shorthand as “AIL-/PSR+ images”. In other words, for this example image, the voxel-space array has an orientation associated with it (`0 = x = AP`, `1 = y = IS`, `2 = z = LR`), but only because of the inherent assumption that the affine will always map to RAS+ physical space.
  - Side note: This can be intuited via the above affine. The `-1` in the first column flips the so-called “PSR+ image” to be ASR+, and the non-diagonal matrix reorients the axes from ASR+ to RAS+. This kind of intuition is part of why we find it helpful to describe voxel space in physical terms.

- _((For reference, the reason why we describe images in “voxel space terms” is because we do a lot of Python-based image processing where we operate directly on the array using tools such as `numpy`, `skimage`, `scipy`, `dipy`, etc. Since we process the array using tools that ignore the context of the image header, it is important for us to know which array axes map to which physical axes (which then get universally transformed into RAS+ physical coordinates by the affine matrix).))_

So, I suppose what @valosekj is truly asking is:

- Assuming the images have an affine that universally maps the array to RAS+ physical coordinates, does axis order matter in voxel space?
- In other words, will “reorienting” the image in voxel space (i.e. modifying the data array + header in tandem) make any difference for `pyradiomics`, given the assumption that the affine will always map the array to RAS+?

Kind regards,  
Joshua

---

_[View the full topic](https://discourse.slicer.org/t/input-orientation-and-axis-indexing-in-pyradiomics-simpleitk-vs-numpy/42332)._