Non-orthogonal IJK to RAS Direction Matrix

Hey there!
I am trying to load CT scans via the DICOM module, which have a non-zero GantryDetectorTilt (not 100% sure it is related) and it seems to cause a non-orthogonal IJK to RAS matrix (see screenshot). Also the case appear “skewed”, i.e. with a shearing angle, in 3D Slicer (see screenshot).

For this case, the ImageOrientationPatient in the DICOM file is:
(0020,0037) DS [1\0\0\0\0.99357185567659-0.1132032137679] # 42, 6 ImageOrientationPatient

I would’ve expected that 3DSlicer complements the perpendicular axis by the cross product, which would lead to an IJK to RAS Direction Matrix of e.g.:
```
[-1, 0, 0]
[0 -0.9936, -0.1132]
[0, -0.1132, 0.9936]
```
I already played a bit around with the settings in Edit→Settings→DICOM (acquisition geometry reularization) but could not make it orthogonal.

Any ideas?

That should be handled directly with the acquisition transform when you load from DICOM. Did you try hardening the volume through the transform?

Also this looks suspicious - there should be only numbers and backslashes in this value.

Was this data processed by some other software or did it come straight from a scanner?

Yes, I tried the option harden regularization transform without success.

Sorry, the DICOM tag was copied from a DICOM visualization software, no clue why a backslash got lost… Accessing the tag directly via pydicom.dcmread() shows no apparent issue though - as far as I can see:

Python 3.12.10 (main, Apr  9 2025, 04:03:51) [Clang 20.1.0 ] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pydicom
>>> pydicom.dcmread("ffc7e0e2fe27516c387ca0e908a40b25.dcm").ImageOrientationPatient
[1, 0, 0, 0, 0.99357185567659, -0.1132032137679]

Can you answer this question and provide any other context?

I ask because I’m surprised the acquisition transform didn’t work since it relies on the per-slice position and orientation data from the dicom header. Is the scan perhaps a multiframe image? (all slices are in one file?)

Loading of tilted-gantry images should work well. There must be something unusual in your image that prevents this mechanism to work. Is the file stored in enhanced multiframe format (single file for the entire 3D stack)? Could you copy all messages related to acquisition normalization that are logged when you load the image (you can access the logs in menu: Help → Report a bug).