SPECTUB image/rotation flips

[KrisThielemans]

We're struggling with image flips etc for SPECT reconstructions. e.g. PR #474 removed some x-flipping, but probably caused bug #452.

We should fix things such that orientation is the same as what is output by clinical systems (which presumably are validated). A complication is that STIR uses a gantry-based coordinate system, while DICOM is patient-based. Assuming that our use of ITK to read DICOM (which handles PatientOrientation etc) is correct , I suggest that we check this by using STIR to convert to DICOM to Interfile (as the Interfile output will always fix the orientation), e.g.

stir_math intf_output.hv one_dicom_file.dcm

An interesting complication is that for SPECT, this depends on the interpretation of detector rotation direction (CW or CCW) and start angle.

@RebeccaGillen @danieldeidda @samdporter I've created this issue to try and document some findings.

[KrisThielemans]

file format pointers

DICOM

https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.8.4.11.html#table_C.8-11 defines NM DICOM angles:

start angle Position of the detector about the patient for the start of the acquisition, in degrees. Zero degrees is referenced to the origin at the patient's back. Viewing from the patient's feet, angle increases in a counter-clockwise direction (detector normal rotating from the patient's back towards the patient's left side)

This definition says that the angle definition depends on the patient orientation.

Interfile 3.3

interfile33.txt

!direction of rotation := <ASCIIlist> CW CW|CCW
CW = clockwise, CCW = counter clockwise

start angle := <Numeric>
0 is top-dead-centre, in degrees -in orientation as specified above

first projection angle in data set := <Numeric>
in degrees expressed with respect to anterior-  angles in direction as specified CW or CCW

This doesn't say if it's w.r.t patient or gantry, nor which side you're looking from. I really don't know what they mean with "in orientation as specified above". Note that "zero" seems 180 different from DICOM.

[danieldeidda]

So I have just check on 3 different datasets dicoms (mediso, and 2 GE from two different hospitals).
They all are supine, feet first. but the start angle is 360 for mediso and 180 for Ge

[KrisThielemans]

Interfile header manipulation experiment

To check the influence of the start angle and CW I did the following:

• converted a GE 670 acquisition (1 detector, 360 degrees rotation, parallel hole collimator, 0008,0104 supine, 0008,0104 feet-first) of a NEMA IQ from DICOM to Interfile (using adding utility that extracts interfile+binary from SPECT dicom data #1122). This gave me an interfile header with start angle 180 (set from 0054,0200) and direction CW (set from 0018,1140)
• I then manipulated the Interfile header to change start angle and rotation direction (I did not change the data)
• I reconstructed with OSEM, output as Interfile, and displayed with amide (it doesn't matter what amide does with Interfile, it's only the relative orientations/flips that I'm interested in )

start angle	CW	CCW
180
150

Clearly, changing the rotation direction from CW to CCW causes a flip along an axis given by the start angle (which makes sense). Therefore, for an acquisition with start angle 0 or 180, it causes an "y-flip", and for an acquisition with start angle 90 or 270, it causes an "x-flip".

[Harry-Marquis-MSKCC]

Hi Kris and STIR SPECT users!

Apologies in advance for a relatively unhelpful response. But I thought I should mention my experience with this issue in STIR (having used STIR extensively for SPECT reconstructions in the past).

I recall a couple of years ago wanting to use STIR on my university cluster. I noticed this "flipping" issue... something I had not seen before when using STIR on my native (MacBook) installation (which was some version of STIR, 3.something). For some reason STIR V 4.0 (which is what the cluster defaulted to) had this flipping issue. I recall (though it was a long time ago) thinking it had something to do with a mismatch in how STIR read in the attenuation map vs the data I wanted to reconstruct. Ultimately, I just used older versions of STIR (either my native MacBook installation, or by specifying an older version of STIR on the cluster).

I don't quite recall why I thought it had something to do with the attenuation map. I haven't dived into the source code in detail, but at some point (between versions) the code changed, and this flipping issue was introduced. I tried to find a workaround by playing with the interfile header data for each of the files used in the recons, but I did not manage to find a solution. I also did not attempt to find the source of the issue in the v4.0 code.

My suggestion would be to look at any changes between STIR versions 3 and 4 to see what change could be causing this. I am certain that the possible fix to this issue lies in the source code of STIR versions prior to 4.0.

All the best!
Harry

[KrisThielemans]

This comment seems mostly related to PR #474 (which added an x-flip in the matrix, but not in the attenuation processing, and therefore probably caused bug #452). We can solve that inconsistency, but I'd rather solve it for good, i.e. reconstructed image should have correct orientation etc, for all start angles and rotation direction.

[mastergari]

Hi all!

While integrating the PinholeSPECTUB code, I regularly referred to the original SPECTUB code to identify any bits of code that should be similarly implemented. One bit of code that I didn’t implement in the pinhole case was the x-axis inversion of the weight matrix. I didn’t implement this because I observed that it flipped the matrix but not the corresponding attenuation map (and explicit mask?).

To obtain the correct orientation of pinhole SPECT reconstructed images in STIR’s coordinate system, I had to invert the x-axis of my projection images before passing them to STIR. I wonder if a similar x-axis inversion of projection data and not the weight matrix would correct this issue. I presume that Carles wrote the code with a consistent coordinate system between the two weight matrix codes.

[Harry-Marquis-MSKCC]

Hi Mathew, I think your suggestion is something that worked for me a few years ago. I found a WhatsApp message I sent to Daniel Deidda a few years ago saying "In order for the recon to be aligned I have to flip the raw (spect) data on the x axis and specify cw rotation other than ccw rotation in the header." Not saying this is the correct fix. But your suggestion reminded me that doing this fixed the flipping issue for me. Regards, Harry Get Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Matthew Strugari ***@***.***> Sent: Sunday, April 2, 2023, 9:56 AM To: UCL/STIR ***@***.***> Cc: Marquis, Harry ***@***.***>; Comment ***@***.***> Subject: [EXTERNAL] Re: [UCL/STIR] SPECTUB image/rotation flips (Discussion #1180) Hi all! While integrating the PinholeSPECTUB code, I regularly referred to the original SPECTUB code to identify any bits of code that should be similarly implemented. One bit of code that I didn’t implement in the pinhole case was the x-axis Hi all! While integrating the PinholeSPECTUB code, I regularly referred to the original SPECTUB code to identify any bits of code that should be similarly implemented. One bit of code that I didn’t implement in the pinhole case was the x-axis inversion of the weight matrix. I didn’t implement this because I observed that it flipped the matrix but not the corresponding attenuation map (and explicit mask?). To obtain the correct orientation of pinhole SPECT reconstructed images in STIR’s coordinate system, I had to invert the x-axis of my projection images. I wonder if a similar x-axis inversion of projection data and not the weight matrix would correct this issue. — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/UCL/STIR/discussions/1180*discussioncomment-5501789__;Iw!!KVWo1iE!UvgY2Bjmjjgid8tvoC5UpEXd_Pofb77K0sm98ng1DGbK45f5LLMMHp7QPDpGDcrqi135FqGD1md0KOrKNgE-W2qr$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/A647R5RRFFPJOL6PV2G2ZRTW7GAPRANCNFSM6AAAAAAWPQ7C2E__;!!KVWo1iE!UvgY2Bjmjjgid8tvoC5UpEXd_Pofb77K0sm98ng1DGbK45f5LLMMHp7QPDpGDcrqi135FqGD1md0KOrKNkx-4_9G$>. You are receiving this because you commented.Message ID: ***@***.***> ===================================================================== Please note that this e-mail and any files transmitted from Memorial Sloan Kettering Cancer Center may be privileged, confidential, and protected from disclosure under applicable law. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this communication or any of its attachments is strictly prohibited. If you have received this communication in error, please notify the sender immediately by replying to this message and deleting this message, any attachments, and all copies and backups from your computer. Disclaimer ID:MSKCC

[KrisThielemans]

Let's try to get some evidence together, with complete info, as otherwise we will get lost. i think we need the following:
0009,1027 (NumberDetectors), 0008,0104 (PatientOrientation), 0054,0200 (start angle) and 0018,1140 (rotation direction), as well as output interfile header from the current SPECT_dicom_to_interfile utility, and info on any flips/rotations needed to match /(converted via stir_math). In addition, even projection DICOM has the following (0020,0032) (ImagePositionPatient) and (0020,0037) (ImageOrientationPatient). I wouldn't know what it means for projections, but let's list it anyway. I've given a few more below.

I also suggest to display the "Interfile converted" CT and STIR-NAC-OSEM Interfile-image with amide. That'll take voxel size into account (but not any offsets, i.e. it will centre each image as far as I know)

Example command lines

CT_file=CT*/*001.dcm
SPECT_file=*.dcm
dcmdump +P 0008,0070 +P 0008,1090  +P 0018,1130 +P 0028,0010 +P 0028,0011 +P 0028,0030 +P 0020,0032 +P 0020,0037 $CT_file
dcmdump +P 0008,0070 +P 0008,1090 +P 0009,1027  +P 0028,0010 +P 0028,0011 +P 0028,0030 +P 0008,0104 +P 0054,0200 +P  0018,1140 +P 0018,1143 +P 0018,1130 +P 0018,1145 +P 0020,0032 +P 0020,0037 $SPECT_file
stir_math CT.hv $CT_file
SPECT_dicom_to_interfile SPECT $SPECT_file 0
env INPUT=SPECTwhatever.hs OSMAPOSL OSEM.par
amide CT.hv 

OSEM.par.txt

[KrisThielemans]

NEMA phantom on GE 670 (FFS,CW, start angle 180)

Needed x and z flip (= 180 degree rotation around y) for images to match. After that a small x-shift was still visible

--- CT
(0008,0070) LO [GE MEDICAL SYSTEMS]                     #  18, 1 Manufacturer
(0008,1090) LO [BrightSpeed]                            #  12, 1 ManufacturerModelName
(0018,1130) DS [136.000000]                             #  10, 1 TableHeight
(0028,0010) US 512                                      #   2, 1 Rows
(0028,0011) US 512                                      #   2, 1 Columns
(0028,0030) DS [0.976562\0.976562]                      #  18, 2 PixelSpacing
(0020,0032) DS [-250.000\-250.000\200.000]              #  26, 3 ImagePositionPatient
(0020,0037) DS [1.000000\0.000000\0.000000\0.000000\1.000000\0.000000] #  54, 6 ImageOrientationPatient
--- SPECT
(0008,0070) LO [GE MEDICAL SYSTEMS]                     #  18, 1 Manufacturer
(0008,1090) LO [Tandem_Discovery_670]                   #  20, 1 ManufacturerModelName
(0009,1027) SL 1                                        #   4, 1 NumberDetectors
(0028,0010) US 128                                      #   2, 1 Rows
(0028,0011) US 128                                      #   2, 1 Columns
(0028,0030) DS [4.415484\4.415484]                      #  18, 2 PixelSpacing
(0008,0104) LO [recumbent]                              #  10, 1 CodeMeaning
(0008,0104) LO [supine]                                 #   6, 1 CodeMeaning
(0008,0104) LO [feet-first]                             #  10, 1 CodeMeaning
(0054,0200) DS [180.75]                                 #   6, 1 StartAngle
(0018,1140) CS [CW]                                     #   2, 1 RotationDirection
(0018,1143) DS [360]                                    #   4, 1 ScanArc
(0018,1130) DS [136.1]                                  #   6, 1 TableHeight
(0018,1145) DS [0]                                      #   2, 1 CenterOfRotationOffset
(0020,0032) DS [-279.683234\-279.083234\280.383234]     #  34, 3 ImagePositionPatient
0020,0037) DS [0.999914\-0.013090\0.000000\0.000000\0.000000\-1.000000] #  56, 6 ImageOrientationPatient

screenshot after inverting x&z axis in amide

TOMOFF_128_EM001_DSLu177_EM.hdr.txt

[RebeccaGillen]

NEMA phantom (with added 60mm sphere) on Siemens Symbia Glasgow Royal Infirmary (FFS, start angle 180, CCW rotation)

Needed x and z flip (= 180 degree rotation around y) for images to match. After that a small z-shift was still visible

--- CT
(0008,0070) LO [SIEMENS]                                #   8, 1 Manufacturer
(0008,1090) LO [Symbia Intevo 16]                       #  16, 1 ManufacturerModelName
(0018,1130) DS [155]                                    #   4, 1 TableHeight
(0028,0010) US 512                                      #   2, 1 Rows
(0028,0011) US 512                                      #   2, 1 Columns
(0028,0030) DS [0.9765625\0.9765625]                    #  20, 2 PixelSpacing
(0020,0032) DS [-249.51171875\-404.51171875\974.5]      #  34, 3 ImagePositionPatient
(0020,0037) DS [1\0\0\0\1\0]                            #  12, 6 ImageOrientationPatient
--- SPECT
(0008,0070) LO [SIEMENS NM]                             #  10, 1 Manufacturer
(0008,1090) LO [Encore2]                                #   8, 1 ManufacturerModelName
(0028,0010) US 128                                      #   2, 1 Rows
(0028,0011) US 128                                      #   2, 1 Columns
(0028,0030) DS [4.7951998710632\4.7951998710632]        #  32, 2 PixelSpacing
(0008,0104) LO [Gastric]                                #   8, 1 CodeMeaning
(0008,0104) LO [99m Technetium]                         #  14, 1 CodeMeaning
(0008,0104) LO [Recumbent]                              #  10, 1 CodeMeaning
(0008,0104) LO [Supine position]                        #  16, 1 CodeMeaning
(0008,0104) LO [Feet-first]                             #  10, 1 CodeMeaning
(0054,0200) DS [180.02661132813]                        #  16, 1 StartAngle
(0054,0200) DS [-0.0266093239188]                       #  16, 1 StartAngle
(0054,0200) DS [180.02661132813]                        #  16, 1 StartAngle
(0018,1140) CS [CC]                                     #   2, 1 RotationDirection
(0018,1143) DS [180]                                    #   4, 1 ScanArc
(0018,1130) DS [155.3]                                  #   6, 1 TableHeight
(0018,1145) DS [0]                                      #   2, 1 CenterOfRotationOffset
(0018,1145) DS [0]                                      #   2, 1 CenterOfRotationOffset
(0020,0032) DS [0\0\1088.4951918125]                    #  20, 3 ImagePositionPatient
(0020,0032) DS [0\0\1088.4951918125]                    #  20, 3 ImagePositionPatient
(0020,0037) DS [1\-8.742278e-008\0\0\0\-1]              #  26, 6 ImageOrientationPatient
(0020,0037) DS [-1\0\0\0\0\-1]                          #  14, 6 ImageOrientationPatient

Screenshot from loading CT and SPECT data (reconstructed in STIR) to AMIDE:

Screenshot after flipping CT in x- and z-directions (residual mis-registration in z-direction):

Screenshot after shifting the CT data by 4 pixels (12mm) in the z-direction:

Output from SPECT_dicom_to_interfile (had to edit the number of projections, rotation extent and Radii info)
NEMA_Symbia_GGC_peak_header.txt
Original header (unedited):
orig_output_checken1.txt

[danieldeidda]

NEMA phantom on Mediso AnyScan (HFS, CCW, start angle 0)

I did not need any flip to match the CT with the recon

CT:
(0008,0070) LO [Mediso] # 6, 1 Manufacturer
(0008,1090) LO [AnyScan SCP-SNs-T1-94R-I0-dcs7] # 30, 1 ManufacturerModelName
(0018,1130) DS [-141] # 4, 1 TableHeight
(0028,0010) US 512 # 2, 1 Rows
(0028,0011) US 512 # 2, 1 Columns
(0028,0030) DS [0.97656\0.97656] # 16, 2 PixelSpacing
(0020,0032) DS [-252.571716-390.511719-62.1875] # 32, 3 ImagePositionPatient
(0020,0037) DS [1\0\0\0\1\0] # 12, 6 ImageOrientationPatient

SPECT
(0008,0070) LO [Mediso] # 6, 1 Manufacturer
(0008,1090) LO [AnyScan SCP-SNs-T1-94R-I0-dcs7] # 30, 1 ManufacturerModelName
(0009,1027) DT [20210901173456.818\20210901173538.455\20210901173620.089\202109011... # 2280,120 Unknown Tag & Data
(0028,0010) US 128 # 2, 1 Rows
(0028,0011) US 128 # 2, 1 Columns
(0028,0030) DS [4.2578\4.2578] # 14, 2 PixelSpacing
(0008,0104) LO [Abdomen] # 8, 1 CodeMeaning
(0008,0104) LO [^90^Yttrium] # 12, 1 CodeMeaning
(0008,0104) LO [recumbent] # 10, 1 CodeMeaning
(0008,0104) LO [supine] # 6, 1 CodeMeaning
(0008,0104) LO [headfirst] # 10, 1 CodeMeaning
(0054,0200) DS [359.999997] # 10, 1 StartAngle
(0054,0200) DS [359.999997] # 10, 1 StartAngle
(0018,1140) CS [CC] # 2, 1 RotationDirection
(0018,1143) DS [360] # 4, 1 ScanArc
(0020,0032) DS [267.621064-140.749991\96.646241] # 32, 3 ImagePositionPatient
(0020,0037) DS [-1\0\0\0\0-1] # 14, 6 ImageOrientationPatient

the image seem OK to me with no registration issue

[KrisThielemans]

From the above it seems that the 3 manufacturers interpret the "ImagePositionPatient" very differently: Looking at the L&P coordinates divided by the pixel size (S is presumably largely determined by bed position):

• GE (start angle 180): {-63.3415, -63.2056}
• Siemens (start angle 180): {0,0}
• Mediso (start angle 0): {62.8543, -33.057}

It's conceivable that GE and Mediso encode a CT/SPECT gantry offset in these. Possibly Mediso uses the detector radius (but how?). Oh well