Space vs orientation

[kretes]

Hello,

I have Nifti data converted from dicom using dicom2niftii with default settings. This means that the data is converted to LAS orientation as per
https://github.com/icometrix/dicom2nifti/blob/dfc18475eb506885a065fe212e8c18791fbc8b04/dicom2nifti/convert_dicom.py#L64

Now, when I read this scan using MONAI - what I get is that the space gets set to 'RAS'
(either by NibabelReader

MONAI/monai/data/image_reader.py

Line 936 in c4ff70b

header[MetaKeys.SPACE] = SpaceKeys.RAS

or when the default affine_lps_to_ras=True in ITKReader)
At the same time my affine matrix is sth like:

tensor([[  -0.7148,    0.0000,    0.0000,  197.2000],
         [  -0.0000,    0.7148,    0.0000, -177.3853],
         [   0.0000,   -0.0000,    1.2500, -278.0000],
         [   0.0000,    0.0000,    0.0000,    1.0000]], dtype=torch.float64),

so the orientation of LAS. while img.meta['space'] says 'RAS'.

I think this is all intended, as I dig up an old comment #4790 (comment) by @wyli saying that img.meta['space'] isn't orientation.

I wonder if it is safe to say that space is a reader_space (as mentioned in the PR) as it can't be altered for a loaded image, right?

For a clearer picture - should there be an orientation field in the image, which gets calculated from the affine, like mentioned in #4224 ?

Wondering about places in MONAI's codebase when there is a check of two images being co-registered. I understand that space isn't important there, as the affine does define the img2world transformation and the images need to have the same `affine, Right?

[KumoLiu]

Hi @kretes, as Wenqi said, the img.meta['space'] here is the base coordinate type. Orientation is relative to the base coordinate type and computed from the affine.
And for this arg affine_lps_to_ras , it mainly adds a flag to switch the different default base coordinate type between different readers. #4789
Hope it helps, thanks!

[kretes]

Since this is something that brings confusion I need to iterate on it:
If the img.meta['space'] is the base coordinate type and affine should be interpreted w.r.t. this space - then I don't get the usefulness of affine_lps_to_ras.

when affine_lps_to_ras=True - what happens is that img.meta['space'] is set to RAS and affine gets flipped between lps and ras. (e.g. ITKReader

MONAI/monai/data/image_reader.py

Lines 331 to 332 in 4c22a27

	if lps_to_ras:
	affine = orientation_ras_lps(affine)

)
But now - since both space and affine changed - we would get exactly the same meaning of the data as with affine_lps_to_ras=False. Flipping base space and affine has no effect of the final orientatation if it would be calculated from both of them. Am I missing something?

How I look at it - depending on the data we read - we need to stay with affine_lps_to_ras=True or in some rare cases set affine_lps_to_ras=False. Whatever we do - the affine we get in the end will always be w.r.t. the RAS space. Will it be 'correct' depends on the user setting affine_lps_to_ras. img.meta['space'] will just remain a record on how was the data read.

[KumoLiu]

Hi @kretes,

• Affine is calculated by using direction(based on base coordinate type) and spacing.
  

  MONAI/monai/data/image_reader.py

  Lines 329 to 330 in 4c22a27

  	affine[:sr, :sr] = direction[:sr, :sr] @ np.diag(spacing[:sr])
  	affine[:sr, -1] = origin[:sr]

• And since you set affine_lps_to_ras=True in ITKReader, and ITKReader by default use LPS https://dicom.innolitics.com/ciods/mr-image/image-plane/00200037, so we flip the first two spatial dimensions in L332.
  

  MONAI/monai/data/image_reader.py

  Line 322 in 4c22a27

  direction = itk.array_from_matrix(img.GetDirection())

  
  

  MONAI/monai/data/image_reader.py

  Lines 331 to 332 in 4c22a27

  	if lps_to_ras:
  	affine = orientation_ras_lps(affine)

• Whether to set affine_lps_to_ras you can refer to the docstring.

MONAI/monai/data/image_reader.py

Lines 175 to 176 in 4c22a27

	affine_lps_to_ras: whether to convert the affine matrix from "LPS" to "RAS". Defaults to ``True``.
	Set to ``True`` to be consistent with ``NibabelReader``, otherwise the affine matrix remains in the ITK convention.

• space here only helps record which base coordinate type to use.

Hope it helps, thanks!