Radiotherapy World :-)

During our daily process, for every patient we acquire a ConeBeam CT before radiation therapy.
Then, with a specific console and a dedicated software we do a coregistration from CBCT just acquired and the patient reference CT image. Then the software output the SRO data : 3 rotation angles (angle X,Y,Z : Euler's angles) and 3 translations as result of the matching. Then the system transmits all data with DICOM protocol to a central server.

Now I want, for further processing, to collect historycal matching data (rotations and translations) from many patients and post-process them.

Into the central server I've found, for every patient and every treatment, many DICOM files with SOP Class UID
"1.2.840.10008.5.1.4.1.1.66.1" Spatial Registration Storage
http://dicom.nema.org/dicom/2013/output/chtml/part03/sect_A.39.html#sect_A.39.1

Inside them I've found the SRO 4x4 affine transformation matrix into the DICOM tag (3006,00C6)
http://dicom.nema.org/dicom/2013/output/chtml/part03/sect_C.20.html#sect_C.20.2

After further investigations I've found how to decode the 3 angles using Euler Theorem with some Python code and pydicom module
https://en.m.wikipedia.org/wiki/Rotation_formalisms_in_three_dimensions#Conversion_formulae_between_formalisms

Angles are OK : they match perfect with angles showed in coregistration console.
But till now I'm not be able to decode translation data.
Dicom standard says:
Equation P-5 "...The fourth column [T1,T2,T3] is the origin of RCSB with respect to RCSA."
http://dicom.nema.org/dicom/2013/output/chtml/part17/chapter_P.html

So, if Tx , Ty , Tz numbers found inside the matrix are the "origin" of transformation, where can I found (or calculate) translation values as showed in coregistration console ?

This is an example.
Coregistration console, after matching, says to me these values:
TRANSLATION (CENTIMETERS)
X 0.2
Y 0.4
Z -0.1

ROTATION (DEGREES)
X -0.5
Y 0.4
Z 1.2

and this is the corresponding 4x4 affine transformation matrix found into SRO .dcm file:
[0.999756, 0.00698126, 0.0209421, -12.914,
-0.00679671, 0.999938, -0.00887082, 43.049,
-0.0210027, 0.00872632, 0.999741, 267.055,
0, 0, 0, 1]

With my Python code, I recalculate the 3x3 rotation submatrix
[0.999756, 0.00698126, 0.0209421,
-0.00679671, 0.999938, -0.00887082,
-0.0210027, 0.00872632, 0.999741]
and I get angles and they match with console :-)

But for numbers found into 1x3 translation matrix
[-12.914,
43.049,
267.055]
I cannot found a corrispondence with translation values showed me by coregistration console.

Any idea how to decode and get translation values as showed in coregistration console ?

Thanks

> 4x4 affine transformation matrix
> [0.999756, 0.00698126, 0.0209421, -12.914,
> -0.00679671, 0.999938, -0.00887082, 43.049,
> -0.0210027, 0.00872632, 0.999741, 267.055,
> 0, 0, 0, 1]

I strongly suspect that the difference you see is due to the ordering of the transformations (translate then rotate, versus rotate then translate). Rotations are not commutative with each other or with translations, so the order is very important.

For a 4x4 matrix like the one above, the numbers in the last column are a translation that is applied after the rotation given by the 3x3 matrix. But perhaps the console is giving a translation that is applied before the rotation, rather than after?

There is an easy way to check. A pre-translation (applied before rotation) is equal to a post-translation multiplied by the inverse of the 3x3 matrix. And likewise, a post-translation is equal to a pre-translation multiplied by the 3x3 matrix.

> I strongly suspect that the difference you see is due to the ordering of the transformations (translate then rotate, versus rotate then translate). Rotations are not commutative with each other or with translations, so the order is very important.

Just replying to myself. The discrepancy between your console translation and the SRO translation is too large to be accounted for by the ordering of the operations. My next guess is that the center-of-rotation is defined differently for the console vs the SRO.

Il giorno lunedì 26 luglio 2021 alle 18:50:22 UTC+2 david...@gmail.com ha scritto:
> > I strongly suspect that the difference you see is due to the ordering of the transformations (translate then rotate, versus rotate then translate).. Rotations are not commutative with each other or with translations, so the order is very important.
> Just replying to myself. The discrepancy between your console translation and the SRO translation is too large to be accounted for by the ordering of the operations. My next guess is that the center-of-rotation is defined differently for the console vs the SRO.

Solved (thanks to a my collegue).
Translation found into 4x4 matrix are absolute values against patient isocenter position.
I find isocenter position into the patient RTPLAN dicom file (SOP Class UID 1.2.840.10008.5.1.4.1.1.481.5 ) , tag (300a, 012c)

I simply calculate difference from rtplan isocenter and matrix value and BINGO: all works perfectly. Values are exactly as showed into coregistration console.
END, problem solved :-)

Solved (thanks to a my collegue).
Translation found into 4x4 matrix are absolute values against patient isocenter position.
I find isocenter position into the patient RTPLAN dicom file (SOP Class UID 1.2.840.10008.5.1.4.1.1.481.5 ) , tag (300a, 012c)

I simply calculate difference from rtplan isocenter and matrix value and BINGO: all works perfectly. Values are exactly as showed into coregistration console.
END, problem solved :-)