CASToR TOF reconstruction

General Discussions
1

Dear CASToR developers and users,

I have a question regarding an issue with CASToR TOF reconstruction.

I will give a brief background of the issue: I have modelled the G.E. Discovery MI (DMI) PET/CT with GATE and simulated a PET acquisition with the NEMA IQ phantom. I have converted the data to the CASToR list-mode format and so far, there are generally no problems. However, when including TOF in the data file I get an increased signal in the reconstructed image in places where I do not expect, e.g., in the lung insertion, but also a quite reduced signal in the spheres.

The TOF information for each event that I write to the binary file I simply take the arrival time difference between crystal1 and crystal2, i.e., time1-time2 and then multiply the difference by 1e+12 to get the delta time in ps. I then save the crystals in the binary file as Crystal ID1 (c1) corresponding to GATE crystal1 and Crystal ID2 (c2) corresponding to GATE crystal2 (since it is mentioned in the general documentation that the TOF delta time is positive when the emission occurs closer to c2.) In the header file I set the TOF resolution to 380 ps and the TOF measurement range to 4900 ps. I decided to only write the true coincidences in the binary file (together with attenuation, normalization, and the inclusion of a span of 2 for indirect slices for segment 0) so that I could efficiently look at the effect of TOF without having to bother with random- and scatter correction.

If I then reconstruct the data, I notice an increased signal in the insertion compartment, as well as a notable reduction in signal between some of the spheres (especially visible between the largest spheres), as opposed to if I reconstruct the data using the -ignore-TOF option (or without including TOF information in neither the binary- nor the header file.) If I reconstruct the same data but increase the TOF resolution to, e.g., 700 ps, the signal in the insertion compartment is reduced and the reduced signal between spheres are no longer present. (I also tested using the GATERootToCastor converter with the TOF resolution to 380 ps yielding similar results.)

I have attached images showing a slice of the three examples that I mentioned (TOF included with 380 ps TOF resolution, TOF included with 700 ps TOF resolution, and with the -ignore-TOF option used.) I have also included profiles through the same slices passing through two of the spheres and the insertion compartment.

Intuitively, this seems to yield erroneous results (with 380 ps TOF resolution), but I cannot seem to understand why this effect occurs. I was hoping someone could help me understand what the issue might be, if I have missed something, or whether I am on the wrong track and have misunderstood the “TOF-induced” results.

I hope to hear from you.

Best regards,
Philip

nemaImages.png
nemaImages.png1050×376 50 KB

nemaProfiles.png

2

Greetings,

The profiles remind me of a nice paper that studied the consequences of over/under estimation of the TOF kernel. Since you use GATE, is it possible that you have made a slight error in setting the TOF resolution? The command in GATE “/gate/digitizer/Singles/timeResolution/setTimeResolution X” defines the single resolution as X. As such, the coincidence resolution is sqrt(2) * X.

Note: My memory tells me that CASTOR extract the coincidence TOF resolution directly from the .mac, so this should not happen. However, you “set it by hand”, which makes it a possibility.

Bests,
Maxime Toussaint

3

Hi Maxime,

Could you remember the name of the paper you mentioned? I am interested in that paper. Thanks!

Best,
Xinjie

4

Hello,

just a comment: for a GATE simulation, the effective coincidence resolution is not just SQRT(2X*^2). If you set X to zero in GATE and draw the ToF histogram for a perfectly centred point source, you will see that the width of the distribution is not zero. There is an intrinsic coincidence time resolution E in GATE, related to the way the time information is stored. So, the effective coincidence resolution is SQRT(2X*^2 + E^2). Now, E is typically less than 100 ps. So, depending on X, it can be negligible.

Best,

Claude

5

Greetings,

On which version of GATE and which type of data file (root, binary, ascci) did you observe this behavior? In the past, I tested a range of TOF resolution with Gate v8.0 using binary output and I did not observe this behavior.

Are you peharps referring to the effect of depth of interaction on coincidence timing resolution? For typical detectors, the effect on timing resolution would indeed be less than 100 ps.

Best,
Maxime Toussaint

6

Hello,

thank you for your quick response, Maxime. You are correct, I had set the single time resolution incorrectly!

Thank you for the help in this matter, your assistance has been greatly appreciated.

Best regards,
Philip

7

It was vGATE 9.0, and we analysed the root output (time difference). The result as such is not surprizing. As far as I understood, the time is set according to the very last interaction resulting from the detection of the single photon in the detector. It includes obviously the effect of variable depth of interaction. We measured a value of 72 ps FWHM. When we added a time resolution of X [ps] (/gate/digitizer/Singles/timeResolution/setTimeResolution X), the measured coincidence time resolution fitted nicely with SQRT(X^2 + X^2 + 72^2).

Now, if you wish to simulate ultra-fast timing resolution (< 100 ps), you need to modify how the time is set in GATE (for example, consider the detection of the first photoelectron).

Best,

8

Greetings,

Oh, you included optical photons in your simulation. I am less familliar in how GATE deal with that case.

In a basic simulation, without optical photons, the time registered for Singles/Coincidences is directly the time of interaction of a gamma with a “CrystalSD”. It does not correspond to reality but it is the best GATE can do when it does not emulate a photodetector and it is good enough, as you said, with TOF resolution >100 ps*.

I believe that some users of GATE + CASToR might not have your insight about the correct manipulation of ultra-fast timing resolution (i.e. adapting GATE timing). As such, it might be usefull to add a comment on that part in the documentation of GATE-to-CASToR model conversion tool since CASToR extract TOF resolution from GATE mac file. It might even be usefull to add a warning in the documentation about the TOF kernel with ultra-fast timing since it can become non-Gaussian in those cases.

Best,
Maxime Toussaint

  • For typical detectors
9

Hi Maxime,

Just for precision, the TOF resolution has to be set by the user. It is the TOF range which is automatically converted from GATE files (from the coincidence window value, and only if not set by the user).

You are right about the warnings though.

Best,
Thibaut