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

[null99 at mails.tsinghua.edu.cn]

Dear Kris,

Thank you very much for the detailed explaining. :-)

I have downloaded them and studying now. :-)

Regards,

Long


In your mail:
>From: "Kris Thielemans" <kris.thielemans at csc.mrc.ac.uk>
>Reply-To: GATE feedback and helpline for Users <gate-users at lphe1pet1.epfl.ch>
>To: <null99 at mails.tsinghua.edu.cn>,
  "'GATE feedback and helpline for Users'" <gate-users at lphe1pet1.epfl.ch>
>Subject: RE: [gate-users] Gate LMF-Sinogram (ECAT7) patch
>
>> 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
> 
> 
> 
> _______________________________________________
> gate-users mailing list
> gate-users at lphe1pet1.epfl.ch
> http://lphe1pet1.epfl.ch/mailman/listinfo/gate-users
>