add Triple events, multiples strategy and changed CoincidenceEvent

[KrisThielemans]

Adding triple coincidences. We're now using arrays of length 2 for CoincidenceEvents, such that it is the same for triples.
Also added a field for how multiples are handled by the scanner.

Also added documentation clarifying TOF conventions.

BREAKS BACKWARDS COMPATIBILITY

• The content of this Pull Request (the Contribution) is intentionally submitted for inclusion in the ETSI software (the Work) under the terms and conditions of the Apache-2.0 License.

[KrisThielemans]

@johnstairs how do we document enums in yardl? My current strategy for the MultipleCoincidenceStrategy doesn't seem to work.

[MaxTousss]

My knowledge about triple events is limited, so take the following with a grain of salt.

The only potential problem I have found with the proposed modifications is the definition of MultipleCoincidenceStrategy.

1. Currently, it only defines rejection or conversion into coincidence pair. In other word, it does not have a value associated with the fact that the format also supports tripleEvents, where they are stored as triple. The intent might be to that one can easily check for the existence of tripleEvents but it feels prone to error.
2. Also, it feels like MultipleCoincidenceStrategy should refer to how multiple events are dealt with and not how they are represented/stored. If I use GATE as a reference, this name feels more appropriate for what GATE calls Policy name for multiple coincidences. Thus, my neophyte view on the matter would be to have MultipleCoincidenceStrategy defines two parameters: something akin to GATE's Policy name and something like TripletContainer or TripletStructure.
3. Lastly, my understanding of triplet events recovery is that you only want to work with triplets that has at least one of the three events with an energy of around 511 keV while also allowing small energy window for the other two. Thus, it feels like one would have two energy windows in that case? Unsure if it is possible in practice, however. If it is, we should be able to store that information in Protocol or something.

[chwlerche]

@MaxTousss thanks for the comments. I'm rather new to this group and still don't know where I can find all things that may have been discussed so far (e.g. where is the MultipleCoincidenceStrategy doc?), so just ignore, if I address things that have been solved already.

For the triples, two cases need to be considered: Triples occurring with pure positron emitters as F-18, C-11 and for non-pure like Ga-68, Iodine, etc. For triples from pure emitters, strategy is to my understanding in most cases conversion to pair of doubles. Other known strategy is rejection as mention. There is currently not so much work done on additional alternatives, and relevance for clinical applications not that important, because probably mainly adding some image noise.

For the second case, strategy should not be conversion into pair of doubles (but using the annihilation gammas as LOR from one event and ignore the tagging prompt gamma after detection). Of course, rejection is also a valid strategy. In this second case, we should have energy window of 511 around the annihilation photons, and another window for the prompt gamma (e.g. 68Ga around 1 MeV, but only approximately. 3 % of branching). This is, in principle, possible, but depends on the used system. It may not always be possible. One probably also needs to coincidence window in that case, as there may pass some time between prompt gamma emission and annihilation. In this case, correct handling may be quite relevant, when the probability of the prompt gamma emission is elevated.

In addition, there is also some work on the Lutetium background, which cause triples (beta-, 80/200/300 keV) and which can be sued for attenuation estimation and Siemens uses it for its quality guard, as far as I know. In this case, strategy should be conversion to two doubles, as Bothe LORs are correct.

[KrisThielemans]

We have discussed this more in a previous meeting, after referring to table 8.2 of the Gate-UsersGuideV7.2.

We agree that "policy" is a better name than "strategy" and have adjusted it accordingly. Also added a little bit more clarification.

The topic of how scanners handle multiple single events is very complicated. For this PR, we just list 2 simple policies and an "other". We will aim to get information on common policies to be able to encode those.

@MaxTousss hopefully the new wording makes it clear that this only discusses how prompts are recorded. Similar issues with triples will be left for later. As an example, if the stream stores "triple coincidences", than it is expected that the "prompt coincidences" will be recorded with a policy of rejectMultiples. It is unclear to me if that is necessary to enforce this (so I wouldn't).

3. Lastly, my understanding of triplet events recovery is that you only want to work with triplets that has at least one of the three events with an energy of around 511 keV while also allowing small energy window for the other two. Thus, it feels like one would have two energy windows in that case? Unsure if it is possible in practice, however. If it is, we should be able to store that information in Protocol or something.

At present, (double) coincidences and triples store energy window information for every single (so, 2 energy windows for a double coincidence, etc). We believe this will address your concern.

[KrisThielemans]

1. The intent might be to that one can easily check for the existence of tripleEvents but it feels prone to error.

That was indeed the intention, but we agree that this is difficult in practice. We might need to have booleans in the header delayedsAreRecorded, triplesAreRecorded etc.

[KrisThielemans]

This PR could easily be extended to quadruples, but we will leave that for later as well.