[gate-users] updated proposal and patches

[Kris Thielemans]

Hi all

> My idea is very simply. Since the LOR of two pair of (x,y,x) and
> director ID
<snip>
> sampling (as you said, isn't it?). Thus we have arc corrected michelogram
> directly.
>

a few comments on all of this.

some more info on the 3D sinogram format can be found in the STIR glossary
and STIR overview for developers (on the documentation section of one of the
STIR websites).

The data organisation in the "Interfile 4.0 proposal for PET" is essentially
very similar to ECAT7 (Without the header), but a bit more general. So, you
can do arc-corrected data, or not, mashed or not etc.
It's then up-to the application how to handle the data. As Claude mentioned
there's the 'purely geometric' view, or the 'connection with detectors'
view. Unfortunately, because of 'interleaving' in traditional PET, these 2
are not the same. This causes me some headaches in STIR, because sometime we
want/need to have one view, sometimes the other. I do not have a neat
solution for this. Still, I don't think this is the business of the data
format.

Note that at present, STIR cannot directly read the 'polar' organisation
proposed by Claude. However, it is easily simulated by taking a ring with
very large radius. Alternatively, some classes (and Interfile keywords)
could be added.

Writing a purely geometric listmode->sinogram converter is fairly easy,
especially with the support provided in STIR. In fact, as I keep saying,
this is mostly done already. As I don't get a reaction from the relevant
people (not that I managed to contact them directly, but I supposed they are
on this list), I will send the relevant (STIR) code in a separate email. It
indeed uses the LMF x,y,z info.

Note that reading the root output is a GATE thing only, while I suppose
reading the LMF data should work for ClearPET scanners as well. correct?

A final note. As soon as you need normalised data (and you do!), you do need
to know about which detector is where etc. Much harder. e.g. I'm not sure if
doing 'arc-correction' before normalisation makes a lot of sense (it might
do, but you'd have to do a non-standard weighting in the arc-correction
obviously).

Kris