[gate-users] Gate LMF-Sinogram (ECAT7) patch

[Kris Thielemans]

> The patch uses uniform spaceing when 
> building sinogram, but with no weighting. 

Weighting is normally the job of the normalisation process, not of the
binning. See also our IEEE MIC proceedings on this (available on my
web-site) if you're interested.

> It simply binning 
> the events into unifromly spaced logical detector ID by their 
> position (x,y,z). (In my understanding, the (x,y,z) position 
> is of the detector ID uniquely specified by the Cylindrical 
> system's rsector, module, submodule, crystal ID, so weighting 
> is a must). I have had a glance at STIR's List data mode 
> classes, it do the similar work, but the list data is based 
> on ECAT system and they have
> (ring,detector) in nature. 

Just for your info, the situation in STIR is a bit more flexible than
that... (GATE users not interested in STIR can stop reading now)

Whatever the list mode data looks like, as long as you have a function
that finds the nearest bin in a 3D sinogram for your event (at a
particular time), the same code can produce the 3D sinogram for your
list mode data. STIR listmode handling uses base classes with virtual
functions in various places. So, if you override one of the defaults,
you get different behaviour. 

So, lm_to_projdata uses the LmToProjData class, which uses the virtual
method get_bin_from_event. Its default implementation calls
event.get_bin(), where event is an object of a class in the CListEvent
hierarchy. Then you'll see that CListEvent::get_bin just uses x,y,z info
and purely geometrical LOR info to find the nearest match.  So that's
what happens 'normally'. (The LMF code I sent you does exactly this).

However, the CListEventECAT* classes know that there is a unique
correspondence between an event and a detector pair, and hence with a
bin in the 3D sinogram (in case there is no mashing nor span). The last
correspondence uses the normal 'sinogram interleaving'. So, if you rebin
ECAT listmode files, you will produce sinograms with interleaving,
exactly the same as what the scanner would do (and we checked this).

If you have a rotating scanner, the default behaviour is a better bet,
or you could override LmToProjData::get_bin_from_event for specfic
handling, as we did for the HiDAC.

Kris