Questions on the implications of the MetaKeys.SPACE with RAS/LPS and image flipping

[MMelQin]

I saw the enums defined for SpaceKeys, RAS and LPS, and the code comment at

MONAI/monai/utils/enums.py

Line 499 in 77fd5f4

DICOM (0020,0032) uses Left-Posterior-Superior or "LPS". This type does not distinguish spatial 1/2/3D.

Needless to say, the LPS is used for human to interpret radiology images and relate to the patient anatomies, but there are a whole set of other metadata to indicate patient orientation, patient position, anatomical orientation type, as well as the image position (patient) and image orientation (patient), with the later two used to calculate the voxel world coordinates and the others help to interpret the image. Questions are then

• The ITKReader, simply defaults to SpaceKey.LPS, unless told to flip the image with affine_lps_to_ras. How does a creator of this class know to flip or not, based on the requirement of the model and input data combination? e.g. if my OWN ImageReader class, similar to ITKReader, only deals with DICOM input, can it stick to LPS and expect the downstream pre-processing transform to deal with the flipping, e.g. OrientationD
• I have looked at some of the inference.json in Model Zoo, but did not find one that specifies affine_lps_to_ras in LoadImageD. How would one expect this option be passed to ImageReader thtough LoadImageD, via **kwargs through LoadImageD?

I plan to stick to LPS in my code as right now it does not use LoadImage and it does not parse the LoadImageD specified in inference.json.
@Nic-Ma @wyli

[wyli]

that's correct @MMelQin, if you only use the ITKReader backend, the default is LPS and there's no need to consult the parameter affine_lps_to_ras. (and yes LoadImageD receives this keyword arg via **kwargs)

[MMelQin]

Thanks @wyli for the confirmation. MONAI Deploy App SDK has its own DICOM series to volume image (ndarray and metadata) converter. I am also contemplating to consume volume images (generated from a DICOM series) from a new API on AWS.